FAQ
While reading the Go language source code for various packages, I've
noticed an inconsistency in how tests are organized. I'm hoping someone
here can help me understand why.

net/http/client.go is in package 'http' but net/http/client_test.go is in
package 'http_test'

While net/http/cookie.go is in package 'http' and net/http/cookie_test.go
is in package 'http'

There are multiple instances of these inconsistencies. If you know why, or
if you can describe the strengths and weaknesses of each, I'd really
appreciate it.

Thanks.

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

  • Brad Fitzpatrick at Mar 19, 2014 at 6:44 pm
    foo.go and foo_test.go should both be in package foo if possible.

    Sometimes it's not possible if your test code needs other packages which
    will then lead to circular dependencies. In that case you need to move
    your test code out into foo_test (its own package) instead. But then that
    means you can't get at foo internals from foo_test and can't poke around
    them and test your internal state.

    Hence all the export_test.go files. That's a convention that bridges foo
    and foo_test: export_test.go gets compiled into package foo and exports
    normally-hidden stuff out into capitalized exported symbols so other tests
    in foo_test.go (package foo_test) can poke at it. That is a pain, so only
    do it if required. Otherwise prefer everything be in the same package.


    On Wed, Mar 19, 2014 at 11:38 AM, Vasko Zdravevski wrote:

    While reading the Go language source code for various packages, I've
    noticed an inconsistency in how tests are organized. I'm hoping someone
    here can help me understand why.

    net/http/client.go is in package 'http' but net/http/client_test.go is in
    package 'http_test'

    While net/http/cookie.go is in package 'http' and net/http/cookie_test.go
    is in package 'http'

    There are multiple instances of these inconsistencies. If you know why, or
    if you can describe the strengths and weaknesses of each, I'd really
    appreciate it.

    Thanks.

    --
    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.
  • Gustavo Niemeyer at Mar 19, 2014 at 7:00 pm

    On Wed, Mar 19, 2014 at 3:44 PM, Brad Fitzpatrick wrote:
    foo.go and foo_test.go should both be in package foo if possible.
    I actually prefer to have things in package foo_test if possible. It
    helps making it clear what is whiteboxed and what is not, and also
    makes the use of the package in tests look closer to how people will
    be interacting with the package in the wild, which often helps
    improving naming while the API is being put in place. It also means
    that handling circular imports is not an exception.

    YMMV


    gustavo @ http://niemeyer.net

    --
    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
postedMar 19, '14 at 6:38p
activeMar 19, '14 at 7:00p
posts3
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase