FAQ
Hi all,
There seems to be at least 3 different ways to stub things out for testing:
1. Create an interface, use one implementation for the real code,
another stubby one for testing.
2. Use a global variable to indirect the call, so it can be overridden
during tests, e.g.:
   var timeNow = time.Now
3. Build different code using tags, e.g.:
   realstuff.go:
   // +build !test
   func foo() { /* real implementation here */ }
   fakestuff_test.go:
   // +build test
   func foo() { /* fake implementation here */ }

Are there any other major ones that I’m missing that people find handy?

I’m starting to lean towards the 3rd above because it has zero runtime
cost, it cleanly separates the real implementation from the fake
implementation, and it doesn’t clutter the test code to override
global variables. But the big downside is that now running just “go
test ./...” doesn’t work anymore, people have to pass the extra “-tags
test”.

How many people would use the 3rd option if “go test” injected a
“test” tag in the build by default? Would the go team be open to this
idea?

This was discussed previously on the ML[1][2] but I’ve never seen any
“official” positioning on this topic from the go team. I’d be game to
send a code review with the change, but I wanted to first see how much
interest (or opposition) there would be.


   [1] Just a couple recent threads on this topic:
   “Proposal/question to make mocking easy”
https://groups.google.com/d/topic/golang-nuts/9QtdejgM8tQ/discussion
   “Stubbing functions for unit testing”
https://groups.google.com/d/topic/golang-nuts/NZQrAFOAo74/discussion

--
Benoit "tsuna" Sigoure

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

  • Dave Cheney at Mar 3, 2016 at 2:30 am
    If you want to propose this, the formal proposal process is at
    https://github.com/golang/proposal.
    On Thursday, 3 March 2016 11:42:26 UTC+11, tsuna wrote:

    Hi all,
    There seems to be at least 3 different ways to stub things out for
    testing:
    1. Create an interface, use one implementation for the real code,
    another stubby one for testing.
    2. Use a global variable to indirect the call, so it can be overridden
    during tests, e.g.:
    var timeNow = time.Now
    3. Build different code using tags, e.g.:
    realstuff.go:
    // +build !test
    func foo() { /* real implementation here */ }
    fakestuff_test.go:
    // +build test
    func foo() { /* fake implementation here */ }

    Are there any other major ones that I’m missing that people find handy?

    I’m starting to lean towards the 3rd above because it has zero runtime
    cost, it cleanly separates the real implementation from the fake
    implementation, and it doesn’t clutter the test code to override
    global variables. But the big downside is that now running just “go
    test ./...” doesn’t work anymore, people have to pass the extra “-tags
    test”.

    How many people would use the 3rd option if “go test” injected a
    “test” tag in the build by default? Would the go team be open to this
    idea?

    This was discussed previously on the ML[1][2] but I’ve never seen any
    “official” positioning on this topic from the go team. I’d be game to
    send a code review with the change, but I wanted to first see how much
    interest (or opposition) there would be.


    [1] Just a couple recent threads on this topic:
    “Proposal/question to make mocking easy”
    https://groups.google.com/d/topic/golang-nuts/9QtdejgM8tQ/discussion
    “Stubbing functions for unit testing”
    https://groups.google.com/d/topic/golang-nuts/NZQrAFOAo74/discussion

    --
    Benoit "tsuna" Sigoure
    --
    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.
  • Tsuna at Mar 6, 2016 at 9:50 am

    On Wed, Mar 2, 2016 at 6:30 PM, Dave Cheney wrote:
    If you want to propose this, the formal proposal process is at
    https://github.com/golang/proposal.
    Done: https://github.com/golang/go/issues/14668

    --
    Benoit "tsuna” Sigoure

    --
    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 3, '16 at 12:42a
activeMar 6, '16 at 9:50a
posts3
users2
websitegolang.org

2 users in discussion

Tsuna: 2 posts Dave Cheney: 1 post

People

Translate

site design / logo © 2022 Grokbase