consensus on using separate *_test packages
roger peppe
rogpeppe at gmail.com
Fri Sep 12 16:49:05 UTC 2014
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.
cheers,
rog.
>
> -eric
>
> [1] http://irclogs.ubuntu.com/2014/07/22/%23juju-dev.html#t15:36
> [2] https://groups.google.com/forum/#!msg/Golang-nuts/dkk0X1tIs6k/nO3CKFqbIxYJ
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
More information about the Juju-dev
mailing list