My axioms of argument are:
1. Just like good code, each unit tests addresses a different concern
in isolation.
2. There are 3 concerns to be tested:
1. Correctness of a small unit of logic.
2. How units of logic are composed.
3. How things are instantiated.
3. Testing 2.1 usually requires internal tests.
4. The correctness of the system is an emergent property of the
correctness of all your tests.
If you accept those axioms, then I agree with Dave: making the test
package external just produces boilerplate.
-
Katherine
On 01/21/2016 02:55 PM, Nate Finch wrote:
[reposting this to the wider juju-dev mailing list]
So, I hit an interesting problem a while back. I have some unit tests
that need to be internal tests, thus they are in 'package foo'.
However, my code needs to use some testhelper functions that someone
else wrote... which are in 'package foo_test'. It's impossible to
reference those, so I had to move those helpers to package foo, which
then either requires that we make them exported (which is exactly like
using export_test.go, which, in the juju-core Oakland sprint, we all
agreed was bad), or all tests that use the helpers need to be in
'package foo'... which means I had to go change a bunch of files to be
in package foo, and change the calls in those files from
foo.SomeFunc() to just SomeFunc().
Given the assumption that some tests at some point will make sense to
be internal tests, and given it's likely that helper functions/types
will want to be shared across suites - should we not just always make
our tests in package foo, and avoid this whole mess in the first place?
(A note, this happened again today - I wanted to add a unit test of a
non-exported function to an existing test suite, and can't because the
unit tests are in the foo_test package)
There seems to only be two concrete benefits to putting tests in
package foo_test:
1. It avoids circular dependencies if your test needs to import
something that imports the package you're testing.
2. It makes your tests read like normal usages of your package, i.e.
calling foo.SomeFunc().
The first is obviously non-negotiable when it comes up... but I think
it's actually quite rare (and might indicate a mixture of concerns
that warrants investigation). The second is nice to have, but not
really essential (if we want tests that are good examples, we can
write example functions).
So, I propose we put all tests in package foo by default. For those
devs that want to only test the exported API of a package, you can
still do that. But this prevents problems where helper code can't be
shared between the two packages without ugliness and/or dumb code
churnm, and it means anyone can add unit tests for non-exported code
without having to create a whole new file and testsuite.
-Nate
--
-
Katherine
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
