doubi9999
2016-11-15 17:03
浏览 103
已采纳

在Go中使用覆盖率信息测试OS.Exit方案(coveralls.io/Goveralls)

This question: How to test os.exit scenarios in Go (and the highest voted answer therein) sets out how to test os.Exit() scenarios within go. As os.Exit() cannot easily be intercepted, the method used is to reinvoke the binary and check the exit value. This method is described at slide 23 on this presentation by Andrew Gerrand (one of the core members of the Go team); the code is very simple and is reproduced in full below.

The relevant test and main files look like this (note that this pair of files alone is an MVCE):

package foo

import (
    "os"
    "os/exec"
    "testing"
)

func TestCrasher(t *testing.T) {
    if os.Getenv("BE_CRASHER") == "1" {
        Crasher() // This causes os.Exit(1) to be called
        return
    }
    cmd := exec.Command(os.Args[0], "-test.run=TestCrasher")
    cmd.Env = append(os.Environ(), "BE_CRASHER=1")
    err := cmd.Run()
    if e, ok := err.(*exec.ExitError); ok && !e.Success() {
        fmt.Printf("Error is %v
", e)
    return
    }
    t.Fatalf("process ran with err %v, want exit status 1", err)
}

and

package foo

import (
    "fmt"
    "os"
)

// Coverage testing thinks (incorrectly) that the func below is
// never being called
func Crasher() {
    fmt.Println("Going down in flames!")
    os.Exit(1)
}

However, this method appears to suffer certain limitations:

  1. Coverage testing with goveralls / coveralls.io does not work - see for instance the example here (the same code as above but put into github for your convenience) which produces the coverage test here, i.e. it does not record the test functions being run. NOTE that you don't need to those links to answer the question - the above example will work fine - they are just there to show what happens if you put the above into github, and take it all the way through travis to coveralls.io

  2. Rerunning the test binary appears fragile.

Specifically, as requested, here is a screenshot (rather than a link) for the coverage failure; the red shading indicates that as far as coveralls.io is concerned, Crasher() is not being called.

Coverage test showing Crasher() not being called

Is there a way around this? Particularly the first point.

At a golang level the problem is this:

  • The Goveralls framework runs go test -cover ..., which invokes the test above.

  • The test above calls exec.Command / .Run without -cover in the OS arguments

  • Unconditionally putting -cover etc. in the argument list is unattractive as it would then run a coverage test (as the subprocess) within a non-coverage test, and parsing the argument list for the presence of -cover etc. seems a heavy duty solution.

  • Even if I put -cover etc. in the argument list, my understanding is that I'd then have two coverage outputs written to the same file, which isn't going to work - these would need merging somehow. The closest I've got to that is this golang issue.


Summary

What I am after is a simple way to run go coverage testing (preferably via travis, goveralls, and coveralls.io), where it is possible to both test cases where the tested routine exits with OS.exit(), and where the coverage of that test is noted. I'd quite like it to use the re-exec method above (if that can be made to work) if that can be made to work.

The solution should show coverage testing of Crasher(). Excluding Crasher() from coverage testing is not an option, as in the real world what I am trying to do is test a more complex function, where somewhere deep within, under certain conditions, it calls e.g. log.Fatalf(); what I am coverage testing is that the tests for those conditions works properly.

  • 写回答
  • 好问题 提建议
  • 关注问题
  • 收藏
  • 邀请回答

3条回答 默认 最新

  • dqhmtpuy94946 2016-11-25 09:36
    已采纳

    With a slight refactoring, you may easily achieve 100% coverage.

    foo/bar.go:

    package foo
    
    import (
        "fmt"
        "os"
    )
    
    var osExit = os.Exit
    
    func Crasher() {
        fmt.Println("Going down in flames!")
        osExit(1)
    }
    

    And the testing code: foo/bar_test.go:

    package foo
    
    import "testing"
    
    func TestCrasher(t *testing.T) {
        // Save current function and restore at the end:
        oldOsExit := osExit
        defer func() { osExit = oldOsExit }()
    
        var got int
        myExit := func(code int) {
            got = code
        }
    
        osExit = myExit
        Crasher()
        if exp := 1; got != exp {
            t.Errorf("Expected exit code: %d, got: %d", exp, got)
        }
    }
    

    Running go test -cover:

    Going down in flames!
    PASS
    coverage: 100.0% of statements
    ok      foo        0.002s
    

    Yes, you might say this works if os.Exit() is called explicitly, but what if os.Exit() is called by someone else, e.g. log.Fatalf()?

    The same technique works there too, you just have to switch log.Fatalf() instead of os.Exit(), e.g.:

    Relevant part of foo/bar.go:

    var logFatalf = log.Fatalf
    
    func Crasher() {
        fmt.Println("Going down in flames!")
        logFatalf("Exiting with code: %d", 1)
    }
    

    And the testing code: TestCrasher() in foo/bar_test.go:

    func TestCrasher(t *testing.T) {
        // Save current function and restore at the end:
        oldLogFatalf := logFatalf
        defer func() { logFatalf = oldLogFatalf }()
    
        var gotFormat string
        var gotV []interface{}
        myFatalf := func(format string, v ...interface{}) {
            gotFormat, gotV = format, v
        }
    
        logFatalf = myFatalf
        Crasher()
        expFormat, expV := "Exiting with code: %d", []interface{}{1}
        if gotFormat != expFormat || !reflect.DeepEqual(gotV, expV) {
            t.Error("Something went wrong")
        }
    }
    

    Running go test -cover:

    Going down in flames!
    PASS
    coverage: 100.0% of statements
    ok      foo     0.002s
    
    已采纳该答案
    评论
    解决 无用
    打赏 举报
  • doufunuo4787 2016-11-24 11:31

    It not common practice to put tests around the Main function of an application in GOLANG specifically because of issues like that. There was a question that is already answered that touched this same issue.

    showing coverage of functional tests without blind spots

    To Summarize

    To summarize it you should avoid putting tests around the main entry point of the application and try to design your application in way that little code is on the Main function so it decoupled enough to allow you to test as much of your code as possible.

    Check GOLANG Testing for more information.

    Coverage to 100%

    As I detailed on on the previous answer since is a bad idea to try getting tests around the Main func and the best practice is to put as little code there as possible so it can be tested properly with out blind spots it stands to reason that trying to get 100% coverage while trying to include the Main func is wasted effort so it better to ignore it in the tests.

    You can use build tags to exclude the main.go file from the tests therefore reaching your 100% coverage or all green.

    Check: showing coverage of functional tests without blind spots

    If you design your code well and keep all the actual functionality well decoupled and tested having a few lines of code that do very little other then calling the actual pieces of code that do all the actual work and are well tested it does't really matter that you are not testing a tiny and not significant code.

    评论
    解决 无用
    打赏 举报
  • dozr13344 2016-11-27 13:08

    Interfaces and mocks

    Using Go interfaces possible to create mock-able compositions. A type could have interfaces as bound dependencies. These dependencies could be easily substituted with mocks appropriate to the interfaces.

    type Exiter interface {
        Exit(int)
    }
    
    type osExit struct {}
    
    func (o* osExit) Exit (code int) {
        os.Exit(code)
    }
    
    type Crasher struct {
        Exiter
    }
    
    func (c *Crasher) Crash() {
        fmt.Println("Going down in flames!")
        c.Exit(1)
    }
    

    Testing

    type MockOsExit struct {
        ExitCode int
    }
    
    func (m *MockOsExit) Exit(code int){
        m.ExitCode = code
    }
    
    func TestCrasher(t *testing.T) {
        crasher := &Crasher{&MockOsExit{}}
        crasher.Crash() // This causes os.Exit(1) to be called
        f := crasher.Exiter.(*MockOsExit)
        if f.ExitCode == 1 {
            fmt.Printf("Error code is %d
    ", f.ExitCode)
            return
        }
        t.Fatalf("Process ran with err code %d, want exit status 1", f.ExitCode)
    }
    

    Disadvantages

    Original Exit method still won't be tested so it should be responsible only for exit, nothing more.

    Functions are first class citizens

    Parameter dependency

    Functions are first class citizens in Go. A lot of operations are allowed with functions so we can do some tricks with functions directly.

    Using 'pass as parameter' operation we can do a dependency injection:

    type osExit func(code int)
    
    func Crasher(os_exit osExit) {
        fmt.Println("Going down in flames!")
        os_exit(1)
    }
    

    Testing:

    var exit_code int 
    func os_exit_mock(code int) {
         exit_code = code
    }
    
    func TestCrasher(t *testing.T) {
    
        Crasher(os_exit_mock) // This causes os.Exit(1) to be called
        if exit_code == 1 {
            fmt.Printf("Error code is %d
    ", exit_code)
            return
        }
        t.Fatalf("Process ran with err code %v, want exit status 1", exit_code)
    }
    

    Disadvantages

    You must pass a dependency as a parameter. If you have many dependencies a length of params list could be huge.

    Variable substitution

    Actually it is possible to do it using "assign to variable" operation without explicit passing a function as a parameter.

    var osExit = os.Exit
    
    func Crasher() {
        fmt.Println("Going down in flames!")
        osExit(1)
    }
    

    Testing

    var exit_code int
    func osExitMock(code int) {
        exit_code = code
    }
    
    func TestCrasher(t *testing.T) {
        origOsExit := osExit
        osExit = osExitMock
        // Don't forget to switch functions back!
        defer func() { osExit = origOsExit }()
    
        Crasher()
        if exit_code != 1 {
            t.Fatalf("Process ran with err code %v, want exit status 1", exit_code)
        }
    }
    

    disadvantages

    It is implicit and easy to crash.

    Design notes

    If you plan to declare some logic below Exit an exit logic must be isolated with else block or extra return after exit because mock won't stop execution.

    func (c *Crasher) Crash() {
        if SomeCondition == true {
            fmt.Println("Going down in flames!")
            c.Exit(1)  // Exit in real situation, invoke mock when testing
        } else {
            DoSomeOtherStuff()
        }
    
    }
    
    评论
    解决 无用
    打赏 举报

相关推荐 更多相似问题