Black-box and white-box testing

[Tim Penhey]

Hi all,

We have two types of tests in the juju-core codebase at the moment, and
I'd like to get some general agreement on how we lay out tests, and what
types of tests are found where.

http://en.wikipedia.org/wiki/White-box_testing
 - tests behaviour of internal methods

http://en.wikipedia.org/wiki/Black-box_testing
 - tests provided functionality without peering into the internal state

Now, from what I've understood from the standard Go practice, is that
these are normally white-box tests, found in the same directory as the
source with <name>_test.go as tests for <name>.go, and to have the tests
inside the same package.

These files are ignored for go build and go install calls, but compiled
and executed using go test.

Now, Juju does different (most of the time).

Tests found in the same package are often in a different package called
<name>_test.  This means that the tests are black box tests enforced by
the language, as only public interfaces can be tested.

This then leads to a name clash when wanting to test both internal
functions, and the public interface using real imports for the same file.

Proposal
========

1) Test files that are in the same directory become white-box tests,
living in the same package as the code.

2) Each directory containing source, gains a "tests" subdirectory that
contains the black-box tests for that package.  The package for the
files in that directory is called "tests".

This way we have clear delineation between the white-box tests and the
black-box tests.

Comments?  Screams?

Tim