Defaulting tests internal to the package

[Katherine Cox-Buday]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160125/eca86a1c/attachment.html>