[go-nuts] Importing from test packages?

On Wednesday, June 26, 2013 4:01:51 AM UTC+8, Rob Miller wrote:

Hi,

I'm working on a project (https://github.com/mozilla-services/heka) that
a) makes heavy use of gomock and gospec for automated testing and b)
supports a plugin API for extensibility. To ease the process of writing
tests for the plugins, we've also got some helper structs defined in our
test support code, with names such as "InputTestHelper" and
"OutputTestHelper". These test helpers contain pre-defined interface mocks
and utility functions that are often needed by tests for input or output
plugins, respectively.

This is all great, expect that we also support plugins that don't
necessarily live in Heka's main 'pipeline' package. There doesn't seem to
be any way to gain access in one package's test code to names that are
defined in a different package's test code. Even though we've written a
bunch of useful test helper code, specifically intending it to be useful
even to other packages, there's no way to expose it.

We've tried putting our test helper code in its own separate, non-test
package to begin with. 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.

Am I right that there's no way to access names from one package's test
code in a different package's test code? If so, would this be something
that is possible or worth considering? Being able to do so would be
extremely useful to us.

Thanks,

-r

On Wednesday, 26 June 2013 08:05:45 UTC-7, David DENG wrote:
What if you move the helper structs into some non-testing files (whose
suffix is not "_test.go"), but still in the core package.

David

On Thursday, June 27, 2013 1:38:52 AM UTC+8, Rob Miller wrote:

This would work, yes. But, well, blech. I'm not happy about the idea of an
`InputTestHelper` struct, which is only *ever* intended to be used by test
code (i.e.inside of "_test.go" files) being forced to be part of the
public, non-test API of our package. Smells bad, man.

Thanks for the suggestion.

-r

On 25 June 2013 21:01, Rob Miller wrote:
We've tried putting our test helper code in its own separate, non-test
package to begin with.

On Wednesday, 26 June 2013 08:26:12 UTC-7, rog wrote:
On 25 June 2013 21:01, Rob Miller <r...@kalistra.com <javascript:>>
wrote:
This is what we do (see launchpad.net/juju-core/testing for example).
It seems to work ok.

On Wed, Jun 26, 2013 at 11:16 AM, Rob Miller wrote:
That link doesn't work for me. I think
https://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/testing/might be what you mean?
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.

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.

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.

-r

--
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Tue, Jun 25, 2013 at 4:01 PM, Rob Miller wrote:
Hi,

I'm working on a project (https://github.com/mozilla-services/heka) that a)
makes heavy use of gomock and gospec for automated testing and b) supports a
plugin API for extensibility. To ease the process of writing tests for the
plugins, we've also got some helper structs defined in our test support
code, with names such as "InputTestHelper" and "OutputTestHelper". These
test helpers contain pre-defined interface mocks and utility functions that
are often needed by tests for input or output plugins, respectively.

This is all great, expect that we also support plugins that don't
necessarily live in Heka's main 'pipeline' package. There doesn't seem to be
any way to gain access in one package's test code to names that are defined
in a different package's test code. Even though we've written a bunch of
useful test helper code, specifically intending it to be useful even to
other packages, there's no way to expose it.

We've tried putting our test helper code in its own separate, non-test
package to begin with. 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.

Am I right that there's no way to access names from one package's test code
in a different package's test code? If so, would this be something that is
possible or worth considering? Being able to do so would be extremely useful
to us.