Re: [golang-dev] Distinct package name to isolate test code.

[Dave Cheney]

What would this change add to coverage or testability of the std library? By convention on Juju we test in a distinct package so we feel we are not cheating by using unexported symbols. However pkg authors are free to apply whatever practice makes sense.

In the spirit of "if it ain't broke", unless this wholesale change significantly improved testability, coverage and reduced lines of code, I don't think this endeavour is worthwhile.

Dave

On 11 Feb 2013 06:28, <r.ekl...@gmail.com> wrote:

By convention all source code named "*_test.go" contains test code. The test code often uses the same package name as the package it is testing. It is also common to append the "_test" suffix to the package name.

There are a few pros and cons about using a distinct package name for test code.

Pros:
* It forces example code to use qualified identifiers which makes it possible to copy a piece of code without having to make modifications.
* It provides an even clearer distinction between the implementation and test code.

Cons:
* No access to unexported functions, variables, etc.
   - Some tests solve this problem by exporting the required internals only for the test code. Example: "src/pkg/fmt/export_test.go". One limitation is that unexported methods can't be called using this approach. Correct me if I'm wrong.

A quick overview of the standard library shows that about 65 packages are using distinct package names ("*_test") for test code, while about 111 are using the same package name. These are approximate numbers since some packages use both.

When it makes sense I prefer using distinct package names for test code and wouldn't mind spending some time going through some of the standard libraries test code and updating it to use distinct package names.

Before doing this I would like to hear what your thoughts are. Am I the only one who prefer this kind or distinct separation? What other pros and cons are there?

/robin

--
 
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Nigel Tao]

On Mon, Feb 11, 2013 at 6:28 AM, <r.ekl...@gmail.com> wrote:
> Before doing this I would like to hear what your thoughts are. Am I the only
> one who prefer this kind or distinct separation? What other pros and cons
> are there?

Losing access to unexported names could be a showstopper for many
packages that do white-box testing. The 65 / 111 split is partly
historical; many of those package tests come from a time when Go was
young, before we settled on some testing conventions. If we were to go
one way, I would actually prefer using the same package name instead
of distinct ones.

But as Dave Cheney said, it ain't broke.

[Rob Pike]

The rule in the standard library is that if a test can be in the same
package ("internal"), it is placed there, to enable testing of
package-private details. Those that cannot be internal arise because
of a dependency cycle: packages that "testing" depends on cannot be
tested by internal tests, a lemma whose proof is left as an exercise
for the reader. If you know of an "external" test that could be
internal, please name it.

Examples are usually external so the code snippets work unmodified.

-rob

[r.eklind.87]

Thank you for describing the rule. I've located 11 cases which could be made
internal in the standard library.

CL: https://codereview.appspot.com/7323044

Cheers /robin