On Wednesday, 26 June 2013 08:26:12 UTC-7, rog wrote:
We've tried putting our test helper code in its own separate, non-test
package to begin with.
This is what we do (see launchpad.net/juju-core/testing for example).
It seems to work ok.
That link doesn't work for me. I thinkhttps://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/testing/
might be what you mean?
This is problematic, however. First, visibility into
the core package changes, so test helper code outside the core package
doesn't work as easily. Also, the helper package needs to import from the
core package, but then the core package's tests need to import from the
helper package, which is a circular import.
If the test helpers can't be factored out without circular imports,
then they're not truly independent.
Nope, they're not. And they're not really meant to be. The helpers are
specific to certain structs and interfaces within our package, and contain
references to other structs and interfaces that are in our package. The
helper absolutely must either live in the package or import from the
package in order to function. If it lives in the package's test code, it's
not available to other packages. If it lives in a separate package's
non-test code, it can't be used from within our package's test code, due to
circular imports. It could live in our package's non-test code, but then
our public API namespace becomes polluted w/ things that have absolutely
nothing to do with the actual functioning of the software.
I'm not sure what you mean by the "core package" here.
When I say "core package" I'm referring to the `heka/pipeline` package,
where most of the interfaces and structs that make up Heka are defined.
Can't you arrange things so that the test helper package
can avoid importing from the core package?
Or else factor the things it needs out of the core package
so that they can both import this other package?
It's possible that we might be able to massively restructure our packaging
so that we can route around this problem. But it wouldn't be a trivial
refactor. And I'm not even sure I could make it work; there have been
several times when I thought I had it put together in a way that would
work, only to realize in fact I did not.
And even if it would work, it's pretty frustrating to have to go down that
road when the entire problem would go away in an instant if I could only
expose test code from one package to test code in another package. Not
saying that my frustration is Go's problem, necessarily, and there might be
significant technical (i.e. implementation-specific) barriers to exposing
test code between packages, but I can't think of any conceptual reasons why
allowing test code to be available btn packages would be a problem.
Am I right that there's no way to access names from one package's test code
in a different package's test code?
That's right. I *think* it's a good thing too - only actual package code
exports functionality; tests are just tests.
Right, this is where I respectfully disagree. Tests *are* just tests. But
tests are code, and sometimes test code needs support code (for clarity, to
remove boilerplate, etc.) just like non-test code. If I write a utility
function (or struct, or interface) in one package, I can make it public so
it's available to other packages, but I can't do so if the utility function
is in a _test.go file. I see no conceptual disadvantage to allowing one
package to expose its test support code so it can be used in tests (and
*only* in tests) in other packages.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.