FAQ
I had thought code within *_test.go were treated normally, except those
files wouldn't be compiled into the package unless you ran the "go test"
command. After trying unsuccessfully to do some init() methods within test
files for Exported variables, I played around with some simple code to test
scoping. My tests are in this repo:

https://github.com/DocSavage/testtest

This is what I discovered:

* Exported package identifiers within *_test.go files aren't visible
outside the package.

* Initialization functions "init()" within *_test.go files can change
package-level variables but those changes are only visible within test
files and not in non-test files of the same package.

It feels like the test files in a package form a subpackage. Since this
wasn't what I expected, I could be doing something stupid or it could be
expected behavior that isn't obvious from the docs.

-Bill

--
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/d/optout.

Search Discussions

  • Dan Kortschak at Aug 12, 2014 at 8:59 pm
    How would things be visible, or be run if they are not compiled? I'm a little confused about how you would see the behaviour you were expecting - remember: test building happens at the package level.

    --
    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/d/optout.
  • Bill Katz at Aug 12, 2014 at 9:02 pm
    To clarify, even if you use "go test -v ./..." the Exported variables
    within the *_test.go files aren't visible outside the package. And even
    within the same package, the non-test files don't see changes made by an
    init() within a test file.
    On Tuesday, August 12, 2014 4:59:55 PM UTC-4, kortschak wrote:

    How would things be visible, or be run if they are not compiled? I'm a
    little confused about how you would see the behaviour you were expecting -
    remember: test building happens at the package level.
    --
    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/d/optout.
  • Wes Freeman at Aug 12, 2014 at 9:08 pm
    I also struggled to get my tests in subpackages to run along with the main
    tests and form a complete coverage output. I ended up scripting them to run
    separately and concatenate the coverage output. Unfortunately that wouldn't
    work in your case. I'd love to see a better way.

    https://github.com/go-cq/cq/blob/master/.travis.yml#L32

    Wes
    On Tue, Aug 12, 2014 at 5:02 PM, Bill Katz wrote:

    To clarify, even if you use "go test -v ./..." the Exported variables
    within the *_test.go files aren't visible outside the package. And even
    within the same package, the non-test files don't see changes made by an
    init() within a test file.

    On Tuesday, August 12, 2014 4:59:55 PM UTC-4, kortschak wrote:

    How would things be visible, or be run if they are not compiled? I'm a
    little confused about how you would see the behaviour you were expecting -
    remember: test building happens at the package level.
    --
    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/d/optout.
    --
    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/d/optout.
  • Dan Kortschak at Aug 12, 2014 at 9:41 pm

    On 13/08/2014, at 6:32 AM, "Bill Katz" wrote:

    To clarify, even if you use "go test -v ./..." the Exported variables within the *_test.go files aren't visible outside the package.
    No, because they import the actual package, not the testing-built package.
    And even within the same package, the non-test files don't see changes made by an init() within a test file.
    They do during testing.

    --
    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/d/optout.
  • Bill Katz at Aug 12, 2014 at 10:04 pm

    On Tuesday, August 12, 2014 5:41:57 PM UTC-4, kortschak wrote:
    On 13/08/2014, at 6:32 AM, "Bill Katz" <bill...@gmail.com <javascript:>>
    wrote:
    To clarify, even if you use "go test -v ./..." the Exported variables
    within the *_test.go files aren't visible outside the package.

    No, because they import the actual package, not the testing-built package.
    That makes the behavior a lot more understandable. So each import will
    only use the non-test version of a package even if compiling under "go
    test".

    And even within the same package, the non-test files don't see changes
    made by an init() within a test file.

    They do during testing.
    In main_test.go (package main):

    subpkg.SaySomething()

    ----
    In subpkg.go (package subpkg):

    var ThingToSay string
    func SaySomething() {
         fmt.Printf(ThingToSay)
    }

    ----
    In subpkg_test.go (package subpkg):

    func init() {
         ThingToSay = "hello, world"
    }
    ----

    The above code won't print anything even under "go test". Given your
    explanation of imports not using test-build packages, regardless of "go
    test" or not, I think it makes sense.

    main_test.go calls the SaySomething() non-test package function, and even
    though the tests within that package have ThingToSay set properly, the
    external package is calling SaySomething() in the non-test package, which
    has no ThingToSay set. So "go test" is not creating a single binary
    (including tests) and then executing that binary -- rather, it is building
    and testing on a package-by-package basis?

    --
    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/d/optout.
  • Dan Kortschak at Aug 12, 2014 at 10:39 pm

    On 13/08/2014, at 7:34 AM, "Bill Katz" wrote:

    The above code won't print anything even under "go test". Given your explanation of imports not using test-build packages, regardless of "go test" or not, I think it makes sense.
    Yes, the two parts of what I wrote need to taken together.

    main_test.go calls the SaySomething() non-test package function, and even though the tests within that package have ThingToSay set properly, the external package is calling SaySomething() in the non-test package, which has no ThingToSay set. So "go test" is not creating a single binary (including tests) and then executing that binary -- rather, it is building and testing on a package-by-package basis?
    Yes.

    --
    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/d/optout.
  • Andrew Bursavich at Aug 13, 2014 at 3:35 am
    It might be worth checking out the recent presentation on Go Testing
    Techniques <https://www.youtube.com/watch?v=ndmB0bj7eyw>.

    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 12, '14 at 8:47p
activeAug 13, '14 at 3:35a
posts8
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase