FAQ
(copied from the style guide thread, since my comment got kinda buried
there)

The point in the style guide about using import . to avoid circular
references in tests seems.... confusing at best, misguided at worst.

When I first read it, it sounded like it gave you access to non-exported
symbols in the package (having never used import ., I figured I must have
missed that critical feature). However, import . does not do that. So,
import . "foo" is no different than import "foo", except the latter makes
it obvious you're working with an external package. Both ways, you're
performing black box testing. The former is just obfuscating the fact for
seemingly zero benefit.

What makes import . ok in this situation, where it is not ok in any other
situation? (I think we can all take for granted it is not ok to use in
almost any other situation)

I just don't like seeing it as a recommended style when it seems to offer
nothing but drawbacks.

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

  • Minux at Feb 23, 2014 at 8:48 pm

    On Sun, Feb 23, 2014 at 10:43 AM, Nate Finch wrote:

    (copied from the style guide thread, since my comment got kinda buried
    there)

    The point in the style guide about using import . to avoid circular
    references in tests seems.... confusing at best, misguided at worst.

    When I first read it, it sounded like it gave you access to non-exported
    symbols in the package (having never used import ., I figured I must have
    missed that critical feature). However, import . does not do that. So,
    import . "foo" is no different than import "foo", except the latter makes
    it obvious you're working with an external package. Both ways, you're
    performing black box testing. The former is just obfuscating the fact for
    seemingly zero benefit.

    What makes import . ok in this situation, where it is not ok in any other
    situation? (I think we can all take for granted it is not ok to use in
    almost any other situation)
    Consider you made a lot of tests for a package P in package P (i.e. not in
    P_test package),
    then you consider import another package which happens to also import P.
    You will have a circular import dependencies in this case.

    If you don't want to rename a lot functions/variables in your tests, you
    can do the import . trick
    and put your tests in P_test package (if you have used any internal
    functions, you will have to
    export them in a export_test.go file.)
    (see, for example, this happens in practice:
    https://codereview.appspot.com/4247048/diff/3012/src/pkg/http/serve_test.go)

    If you start from scratch, then probably it's better to just put all your
    tests in P_test package.

    PS: most of the uses in the std library is actually testing depends the
    package being tested.
    And I don't think this scenario will happen often in practice.

    --
    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.
  • Benjamin Measures at Feb 23, 2014 at 9:43 pm

    On Sunday, 23 February 2014 15:43:31 UTC, Nate Finch wrote:

    I just don't like seeing it as a recommended style when it seems to offer
    nothing but drawbacks.
    It isn't exactly an endorsement:
    Except for this one case, do not use import . in your programs.
    https://code.google.com/p/go-wiki/wiki/Style#Import_Dot

    An example of the case described is in testing the strings package, where
    the testing package itself imports strings. The circular dependency is
    otherwise unavoidable, so there's just no choice.

    IOW, I read it as "except for when it's absolutely unavoidable as described
    in this one case, do not use import . in your programs."

    --
    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 Symonds at Feb 23, 2014 at 10:29 pm
    The idea behind that part of the style guide is this:

    We recommend that tests are in the same package as the code being
    tested. That results in test code that uses names without a package
    selector (i.e. "Index" rather than "strings.Index"). In cases where
    being in the same package is impossible (usually because the package
    under test is a dependency of package "testing") a dot import permits
    the test code to "look right" in that sense. It is unfortunate that
    unexported names cannot be used, but usually for such low level
    package that does not turn out to be too big a problem.

    --
    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.
  • Minux at Feb 23, 2014 at 11:08 pm

    On Sun, Feb 23, 2014 at 5:29 PM, David Symonds wrote:

    The idea behind that part of the style guide is this:

    We recommend that tests are in the same package as the code being
    tested. That results in test code that uses names without a package
    Now I don't understand why we recommend this? What's the rationale behind
    this?

    Personally, I always put tests in a separate package and use export_test.go
    to export internal functions should accessing them be necessary (most times
    not).

    There is at least one problem in always put test in the same package, that
    is
    writing testable example.

    I did some statistics, of all test files in $GOROOT/src/pkg, 292 of them are
    in the same package, and 202 of them are in the _test package.
    Of the 292 test source files, 21 of them are named
    (export|internal)_test.go.

    --
    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 Feb 23, 2014 at 11:55 pm

    On 23 Feb 2014 23:08, "minux" wrote:
    On Sun, Feb 23, 2014 at 5:29 PM, David Symonds wrote:

    The idea behind that part of the style guide is this:

    We recommend that tests are in the same package as the code being
    tested. That results in test code that uses names without a package
    Now I don't understand why we recommend this? What's the rationale behind
    this?

    Personally, I always put tests in a separate package and use
    export_test.go
    to export internal functions should accessing them be necessary (most times
    not).

    There is at least one problem in always put test in the same package, that is
    writing testable example.
    I like to think that all external tests are examples to some extent.
    Importing the package in the same way as any other client means that the
    code looks the same as any other client's code, so can be easily copied
    into another context and is familiar when read. When writing the tests
    (often the first time that a package is exercised), it gives a good feel
    for how the package names work in practice too.

    So I tend to support minux and Nate's skepticism here.
    I did some statistics, of all test files in $GOROOT/src/pkg, 292 of them are
    in the same package, and 202 of them are in the _test package.
    Of the 292 test source files, 21 of them are named
    (export|internal)_test.go.
    --
    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.
  • David Symonds at Feb 24, 2014 at 12:09 am

    On 24 February 2014 10:07, minux wrote:
    On Sun, Feb 23, 2014 at 5:29 PM, David Symonds wrote:

    The idea behind that part of the style guide is this:

    We recommend that tests are in the same package as the code being
    tested. That results in test code that uses names without a package
    Now I don't understand why we recommend this? What's the rationale behind
    this?
    It's so the test can access unexported names, which can make it easier
    to test the parts of the code that need the most testing.
    Personally, I always put tests in a separate package and use export_test.go
    to export internal functions should accessing them be necessary (most times
    not).
    That gets the same effect, via a more convoluted route.
    There is at least one problem in always put test in the same package, that
    is
    writing testable example.
    Examples are good, but they are not tests.
    I did some statistics, of all test files in $GOROOT/src/pkg, 292 of them are
    in the same package, and 202 of them are in the _test package.
    Of the 292 test source files, 21 of them are named
    (export|internal)_test.go.
    Stats based on the standard library aren't going to be useful for
    something like this, since there's a strong bias towards things that
    are dependencies of the testing package, but even given that you've
    found that the majority of tests are in the package being tested.

    --
    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.
  • Nate Finch at Feb 24, 2014 at 3:07 pm

    On Sunday, February 23, 2014 5:29:04 PM UTC-5, David Symonds wrote:
    The idea behind that part of the style guide is this:

    We recommend that tests are in the same package as the code being
    tested.

    Yes, I agree with this. It lets you write internal functions that are very
    testable, but may not have the API you wish to expose (which might be more
    difficult to test). Minux's export_test seems like a hack that is far
    worse than just writing same-package tests. Exporting internal functions
    to be used in what would be otherwise external tests means your external
    tests aren't really external, and even worse, confuse the issue by using
    external-looking functions that the actual package doesn't expose.

    a dot import permits the test code to "look right"
    That seems like a terrible reason to do anything :) If they're going to
    be external tests, why not just make them look like external tests. Making
    them look like internal tests seems to offer no benefit.

    --
    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 Feb 24, 2014 at 5:18 pm

    On 24 February 2014 15:07, Nate Finch wrote:
    On Sunday, February 23, 2014 5:29:04 PM UTC-5, David Symonds wrote:

    The idea behind that part of the style guide is this:

    We recommend that tests are in the same package as the code being
    tested.

    Yes, I agree with this. It lets you write internal functions that are very
    testable, but may not have the API you wish to expose (which might be more
    difficult to test). Minux's export_test seems like a hack that is far worse
    than just writing same-package tests. Exporting internal functions to be
    used in what would be otherwise external tests means your external tests
    aren't really external, and even worse, confuse the issue by using
    external-looking functions that the actual package doesn't expose.
    I think this cuts both ways. There are usually only a small number
    of values to expose in this way and having them all in one
    place (export_test.go) makes it obvious where all the test-required
    loopholes are. Personally, I think it's nice to have external
    tests when feasible. I've done it (and still do it) both ways though - each
    approach has its own merits.
    a dot import permits the test code to "look right"

    That seems like a terrible reason to do anything :) If they're going to be
    external tests, why not just make them look like external tests. Making
    them look like internal tests seems to offer no benefit.
    One benefit is that the test style is the same throughout.
    If your testing framework changes such that you need the "."
    import, you don't have much work to do.

    --
    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
postedFeb 23, '14 at 3:43p
activeFeb 24, '14 at 5:18p
posts9
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase