FAQ
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

--
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.

Search Discussions

  • David DENG at Jun 26, 2013 at 3:12 pm
    What if you move the helper structs into some non-testing files (whose
    suffix is not "_test.go"), but still in the core package.

    One possible disadvantage is that they are also exported as part of the
    core package. Adding some comments may help.

    David
    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
    --
    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.
  • Rob Miller at Jun 26, 2013 at 5:38 pm

    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.

    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.

    One possible disadvantage is that they are also exported as part of the
    core package. Adding some comments may help.
    Thanks for the suggestion.

    -r




    David
    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
    --
    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.
  • David DENG at Jun 27, 2013 at 12:29 am
    On the other hand, you have to exported the helpers anyway, and write
    comments for them. Given a good naming, it is not that bad. I love a
    package accompany with test supporting.

    David
    On Thursday, June 27, 2013 1:38:52 AM UTC+8, Rob Miller wrote:
    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.

    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.

    One possible disadvantage is that they are also exported as part of the
    core package. Adding some comments may help.
    Thanks for the suggestion.

    -r




    David
    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
    --
    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.
  • Roger peppe at Jun 26, 2013 at 3:26 pm

    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.
    This is what we do (see launchpad.net/juju-core/testing for example).
    It seems to work ok.
    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.

    I'm not sure what you mean by the "core package" here.
    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?
    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.

    --
    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.
  • Rob Miller at Jun 26, 2013 at 6:16 pm

    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:
    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 think
    https://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.

    -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.
  • Kyle Lemons at Jun 26, 2013 at 7:53 pm
    The only way I can think of to have something in your main package that is
    not generally part of the exported API but can be at the whim of the
    builder is to put it in a file and guard it with build tags. I don't know
    if the go tool will rebuild transitive dependencies that depend on a
    specified build tag or not, though.

    On Wed, Jun 26, 2013 at 11:16 AM, Rob Miller wrote:
    On Wednesday, 26 June 2013 08:26:12 UTC-7, rog wrote:
    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.
    This is what we do (see launchpad.net/juju-core/**testing<http://launchpad.net/juju-core/testing>for example).
    It seems to work ok.
    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?
    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.

    -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.

    --
    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.
  • Maxim Khitrov at Jun 26, 2013 at 3:28 pm
    I have the exact same problem with my IMAP package. I wrote a
    framework for testing the client against a scripted server, but there
    is no way for other packages to use that code in their own tests.

    Just like you, I exported some essential functionality from the core
    package via an interface [1], and created a separate package that
    contains a copy of the testing code. The circular import problem does
    mean that the code has to be duplicated, though I'm actually making
    some improvements to the script execution that weren't needed for
    testing the core package.

    I agree that it would be nice to have some way of exporting additional
    names when the package is used in the testing context.

    [1] http://godoc.org/code.google.com/p/go-imap/go1/imap#MockServer
    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.
    --
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 26, '13 at 12:23a
activeJun 27, '13 at 12:29a
posts8
users5
websitegolang.org

People

Translate

site design / logo © 2017 Grokbase