Black-box and white-box testing

[Frank Mueller]

> That's not quite true. There's a convention of making private interfaces
> available to the external tests by exporting them in an export_test.go
> file. It only goes a certain way, but it does mean the boundary isn't strict.

Yes, that's a great benefit staying with our tests against the API and still have a not exported way to call private functions just for testing if it is needed.

> For myself, I like the fact that when writing tests against the publicly
> visible API, we use qualified identifiers just like any external package.
> It gives me a feel for how the API will feel to use in practice, and
> it also means that
> the testing code is trivial to factor to another package if necessary.

+1

>> 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".
> 
> I'm not keen on this proposal. I think "go test somepkg" should
> test somepkg, as far as is feasible.

Putting tests in own directories inside the package directories is no common go idiom, many editor extensions aren't working this way. I'm very often test while coding, so from inside the editor and with the package code file I'm working on open I'm directly starting the according tests.

> I have another suggestion. Rather than changing every single test
> we currently have, we could establish a convention that white box
> tests live in files named *_intern_test.go.

+1

mue

--
** Frank Mueller <frank.mueller at canonical.com>
** Software Engineer - Juju Development
** Canonical