consensus on using separate *_test packages

[Tim Penhey]

On 13/09/14 04:49, roger peppe wrote:
> On 12 September 2014 16:55, Eric Snow <eric.snow at canonical.com> wrote:
>> In Go we put tests in *_test.go files that are only built when
>> testing.  There are two conventions for what package to declare in
>> those files (relative to the corresponding non-test package):
>> "<package>" and "<package>_test".  In our code we have a mix of both.
>> This can be confusing.  We should come to a consensus on which to use
>> and stick with it, both for new code and when given the opportunity
>> while refactoring.  (As usual, a whole-sale refactor wouldn't be a
>> good idea).
>>
>> This came up on IRC a couple months back. [1]  At the time I referred
>> to a post from Gustavo on golang-nuts where he stated a preference for
>> using a separate package for *_test.go files. [2]  Also note that
>> there are some cases where test files must be in a separate package
>> (e.g. to break circular imports).  So unless we always use separate
>> test packages, we will almost certainly end up with a mix (which is
>> exactly the issue at hand!).
>>
>> From my perspective, I agree with Gustavo that using a separate _test
>> package is a good idea.  So I would favor us being consistent in doing
>> that. :)
> 
> I think there's a place for both approaches. All else being equal, I
> prefer to have
> tests in an external package, testing using the public API and using as few
> internal details as possible.
> 
> But sometimes it's good to write tests for functions that are intimately
> connected to the internals of a package, and in that case I think it's
> better to write internal tests (with the _test.go file in the same package)
> rather than jumping through hoops to try to make them external.

Please excuse the late reply as I was away for a few days.

I agree with Rog here in that there should be a strong preference to
test the package API using an "_test" package.

There are times when additional internal tests are also useful, but
generally we test the package API.

Others have gone into more detail, but I just wanted to say which side
of the fence I was on.

Tim