I've got to toss another +1 for tests at both levels. One set of tests are tests against your contract to outsiders. Another is confidence that your internals are resilient. There are a ton of cases I can think of such as internal code that validates changes in state, validates various forms of input, deals with internal changes to document structure over time. Ideally, when an external contract test fails, one of the internal ones just blew up to point directly at the culprit within all your internal code.
Yes, it can mean that internal tests need to be kept up to date more as the internals change, but even then tests provide another layer of "did you cover all these cases in your refactoring". On Sun, Jan 24, 2016 at 4:47 PM Tim Penhey <[email protected]> wrote: > I'm going to throw my cool-blue paint against the bike shed. > > I disagree that we should change the default expectations of package tests. > > By default, package tests should be external tests, small and fast, not > full stack, and parameterize from above rather than patch. > > However, I also see much value in internal unit tests for exactly the > same reason as Nate and Roger. It gives me confidence in my > implementation. These tests have nothing to do really with the exposed > interface of the package, but with the current implementation. > > This whole issue is close to my heart right now as I deal with model > migrations. Many of the tests I am writing are internal tests. > > Tim > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
