Defaulting tests internal to the package

[Rick Harding]

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 <tim.penhey at canonical.com> 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
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160125/37c8c55f/attachment.html>