解析 Golang 测试（1）- 原生支持

时间：2022-9-2 作者：smarteng 分类： Go语言

开篇

我们在开发需求时，常常需要关注四个方面：

是否和需求匹配；
代码是否足够健壮，安全；
性能是否达标；
是否具备足够的扩展性，利于后期迭代维护。

第四点更多地关注在整体业务架构的设计上，是一个需要产研共同努力才可能达到的理想状态。前三点则是业务交付必须慎重考量和保障的。

围绕着 Golang 代码的测试，其实有很多可以聊，包括原生的支持，mock, stub, benchmark 等，这方面开源的库也很，这些其实或多或少都在用，但是没有很系统地梳理过。希望借着这个系列回顾一下。

单测和 benchmark 相关的代码，的确不会真正产生业务价值，他们的存在，是为了让你更好的理解自己的系统，对代码更有自信，相关的逻辑更加清晰。

测试相关的能力，我更愿意把它们理解为是一个有力的工具，你可以用也可以不用。如果你是一个经验丰富的开发者，对自己的代码极为自信，那么可能只针对关键case写测试，甚至不写都ok，这是一个case by case 的问题。但从我自身来说，我希望首先能够把这些工具熟悉和掌握，这样才能在有需要的时候派上用场。

今天我们先来看看 Golang 原生提供的 testing 包对测试的支持。

testing 介绍

testing 包支持对 Golang package 进行自动化测试，它需要与 go test 命令搭配使用，这样会自动执行带有 func TestXxx(*testing.T) 签名的函数；
在 TestXxx 函数内，使用 Error , Fail 或相关的方法来表明测试失败。 t.Error* 会报告失败，但不会阻塞测试后续流程， t.Fatal* 则会报告测试失败，并立刻停止测试。
包含测试函数的文件需要以 _test.go 结尾，文件内可以包含多个 TestXxx 函数。_test.go 文件需要和被测函数放到同一个包下，在正常包编译时会被忽略，而执行 go test 命令时会被识别。
执行 go help test 或 go help testflag 可以了解命令细节，这部分可以参考附录或官方命令文档。

我们来看一个简单的测试函数:

func TestAbs(t *testing.T) {
    got := Abs(-1)
    if got != 1 {
        t.Errorf("Abs(-1) = %d; want 1", got)
    }
}
复制代码

注意：虽然在这个例子里，被测函数是 Abs，同时测试函数名字也是 TestAbs，实际上二者不一定需要完全匹配，TestXxx 的命名只是为了区分不同的测试场景，Xxx 和被测函数名不是强绑定。在一个场景中可能需要调用多个函数进行资源的创建和清理。

多组输入输出测试

通常情况下我们会希望待测函数针对一系列输入都能给出正确的输出，需要验证各个场景，而不是简单的测试单个case就结束。这个时候我们就可以把测试的 input 和 output 成对组装起来，给出一个数组。然后用一次 for 循环依次执行，校验输出是否符合预期。这种模式的测试叫做 Table-Driven Test ，包含输入输出的数组就是一个 table。

假定我们有一个返回 a,b 中最小值的函数 IntMin

package main

import (
    "fmt"
    "testing"
)

func IntMin(a, b int) int {
    if a < b {
        return a
    }
    return b
}
复制代码

一个最简单的测试case只给了一组输入输出：

func TestIntMinBasic(t *testing.T) {
    ans := IntMin(2, -2)
    if ans != -2 {
        t.Errorf("IntMin(2, -2) = %d; want -2", ans)
    }
}
复制代码

如果我们希望给出多组输入输出，也叫做 Table-Driven Tests ，可以这样做：

func TestIntMinTableDriven(t *testing.T) {
    var tests = []struct {
        a, b int // 输入
        want int // 输出
    }{
        {0, 1, 0},
        {1, 0, 0},
        {2, -2, -2},
        {0, -1, -1},
        {-1, 0, -1},
    }

    for _, tt := range tests {
        testname := fmt.Sprintf("%d,%d", tt.a, tt.b) // 测试case名称
        t.Run(testname, func(t *testing.T) {
            ans := IntMin(tt.a, tt.b)
            if ans != tt.want {
                t.Errorf("got %d, want %d", ans, tt.want)
            }
        })
    }
}
复制代码

t.Run 支持执行子测试，可以使用 go test -v 来看这些子测试的结果。（-v 代表 verbose，即输出执行测试过程中的日志，可以参考附录部分的 testflag）。

执行上面的多组输入输出场景，我们会得到下面的结果：

$ go test -v
== RUN   TestIntMinBasic
--- PASS: TestIntMinBasic (0.00s)
=== RUN   TestIntMinTableDriven
=== RUN   TestIntMinTableDriven/0,1
=== RUN   TestIntMinTableDriven/1,0
=== RUN   TestIntMinTableDriven/2,-2
=== RUN   TestIntMinTableDriven/0,-1
=== RUN   TestIntMinTableDriven/-1,0
--- PASS: TestIntMinTableDriven (0.00s)
    --- PASS: TestIntMinTableDriven/0,1 (0.00s)
    --- PASS: TestIntMinTableDriven/1,0 (0.00s)
    --- PASS: TestIntMinTableDriven/2,-2 (0.00s)
    --- PASS: TestIntMinTableDriven/0,-1 (0.00s)
    --- PASS: TestIntMinTableDriven/-1,0 (0.00s)
PASS
ok      examples/testing    0.023s
复制代码

执行单个测试函数

如果在一个包下，有很多个测试case，而我们只希望执行某一个单独的 TestXxx 函数，可以使用

go test -v -run TestXxx

查看覆盖率

单测覆盖率是个老生常谈的问题了，很多规范会要求达到 80% 以上，并且一定要有 assert （即明确地判断待测函数的动作是否符合预期），而不能只是简单打印结果的伪测试。

如果我们希望知道某个包下，单测的覆盖率，可以使用这个命令：

go test -coverprofile=coverage.out

你会得到相应的覆盖率结果：

PASS
coverage: 50.0% of statements
ok      ./math 2.073s

复制代码

Golang 会把覆盖率数据存储在 coverage.out （根据你的 -coverprofile 参数的值），如果希望以可视化的页面来呈现覆盖率，可以执行下面的命令：

go tool cover -html=coverage.out

此时会自动打开浏览器，呈现覆盖的结果

undefined

绿色的文本标示已经覆盖，红色的代表着未覆盖。

Benchmarks

形如 func BenchmarkXxx(*testing.B) 的函数就是 testing 支持 benchmark 测试，可以使用 go test 命令配合上 -bench 选项来执行。

运行 go test -bench=. 会运行所有的 benchmarks。

如果你希望只运行某个函数，可以显式地通过参数声明函数名，如 go test -bench=XXX

比如我们需要测试 rand 包下的 Int() 函数的性能，可能写出如下的 benchmark:

func BenchmarkRandInt(b *testing.B) {
    for i := 0; i < b.N; i++ {
        rand.Int()
    }
}

// output: 
// BenchmarkRandInt-8   68453040        17.8 ns/op
复制代码

输出的结果意味着 for 循环执行了 68453040 次，速度为每次 17.8 ns。

如果有些情况下我们需要先做一些耗时的资源初始化操作，不希望纳入到计时中，可以使用 *testing.B 自带的 ResetTimer() 来重置时间。

func BenchmarkBigLen(b *testing.B) {
    big := NewBig()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        big.Len()
    }
}
复制代码

Main

Go 1.14 版本引进了 TestMain 的能力，当需要针对一个单测或benchmark执行一些额外的操作（比如资源的创建/回收），可以使用 testing 支持的 Main 函数机制。

如果一个测试文件声明了下面签名的函数（注意，这是你自己写的，不是testing库内置的）：

func TestMain(m *testing.M)
复制代码

当你使用 go test 执行测试的时候，就不会直接执行 TestXxx 或 benchmark了，而是在 main goroutine 中开始执行 TestMain 。

一个库中只能有最多一个 TestMain ，否则就会出现函数名重复；
*testing.M 包含了唯一的方法 Run() ，它会执行所有当前包下的 TestXxx 函数，并返回一个 os.Exit 可以识别的 code。所以最简单的 TestMain 的实现是下面这样：

func TestMain(m *testing.M) { os.Exit(m.Run()) }
复制代码

如果在你的 TestMain 中没有调用 os.Exit，运行 go test 命令后会收到的错误码是0，即便有测试失败也是如此。

下面我们给个例子：

package mypackagename

import (
    "testing"
    "os"
)

func TestMain(m *testing.M) {
    log.Println("Do stuff BEFORE the tests!")
    exitVal := m.Run()
    log.Println("Do stuff AFTER the tests!")

    os.Exit(exitVal)
}

func TestA(t *testing.T) {
    log.Println("TestA running")
}

func TestB(t *testing.T) {
    log.Println("TestB running")
}
复制代码

执行结束后的结果为：

2021/12/29 00:32:17 Do stuff BEFORE the tests!
2021/12/29 00:32:17 TestA running
2021/12/29 00:32:17 TestB running
PASS
2021/12/29 00:32:17 Do stuff AFTER the tests!
复制代码

需要注意的是， TestMain 是一个包级别的设定，如果你是需要在每个测试中，都进行资源的创建和释放，建议还是自行在 TestXxx 中处理。

其实如果是在测试case执行前进行一些初始化，我们用类似 init() 这样的机制也能实现，但使用 TestMain 依然会带来两个好处：

隔离测试代码与正常业务逻辑
假设你在测试环境不希望和线上一样，连接真实的 MySQL 实例，而是希望用 sqlite 内存数据库来 mock 一些简单的case，就可以把 mock 的实例初始化放在 TestMain，这样在正常的业务逻辑中是看不到的，心智负担会小一些。
执行资源清理

前面有提到，如果测试结束了，你希望释放资源，就可以在 m.Run 之后直接处理即可，TestMain 相当于提供了 BeforeTest 和 AfterTest 语义的钩子。下面给出一个例子的前后对比。

old


func TestDBFeatureA(t *testing.T) {
    models.TestDBManager.Setup()
    defer models.TestDBManager.Exit()

    // Do the tests
}
func TestDBFeatureB(t *testing.T) {
    models.TestDBManager.Setup()
    defer models.TestDBManager.Exit()

    // Do the tests
}
复制代码

new

func TestDBFeatureA(t *testing.T) {
    defer models.TestDBManager.Reset()

    // Do the tests
}
func TestDBFeatureB(t *testing.T) {
    defer models.TestDBManager.Reset()

    // Do the tests
}
func TestMain(m *testing.M) {
    models.TestDBManager.Setup()
    // os.Exit() does not respect defer statements
    code := m.Run()
    models.TestDBManager.Exit()
    os.Exit(code)
}
复制代码

附录

go help test 命令

$ go help test

usage: go test [build/test flags] [packages] [build/test flags &amp; test binary flags]

'Go test' automates testing the packages named by the import paths.
It prints a summary of the test results in the format:

        ok   archive/tar   0.011s
        FAIL archive/zip   0.022s
        ok   compress/gzip 0.033s
        ...

followed by detailed output for each failed package.

'Go test' recompiles each package along with any files with names matching
the file pattern "*_test.go".
These additional files can contain test functions, benchmark functions, fuzz
tests and example functions. See 'go help testfunc' for more.
Each listed package causes the execution of a separate test binary.
Files whose names begin with "_" (including "_test.go") or "." are ignored.

Test files that declare a package with the suffix "_test" will be compiled as a
separate package, and then linked and run with the main test binary.

The go tool will ignore a directory named "testdata", making it available
to hold ancillary data needed by the tests.

As part of building a test binary, go test runs go vet on the package
and its test source files to identify significant problems. If go vet
finds any problems, go test reports those and does not run the test
binary. Only a high-confidence subset of the default go vet checks are
used. That subset is: 'atomic', 'bool', 'buildtags', 'errorsas',
'ifaceassert', 'nilfunc', 'printf', and 'stringintconv'. You can see
the documentation for these and other vet tests via "go doc cmd/vet".
To disable the running of go vet, use the -vet=off flag. To run all
checks, use the -vet=all flag.

All test output and summary lines are printed to the go command's
standard output, even if the test printed them to its own standard
error. (The go command's standard error is reserved for printing
errors building the tests.)

Go test runs in two different modes:

The first, called local directory mode, occurs when go test is
invoked with no package arguments (for example, 'go test' or 'go
test -v'). In this mode, go test compiles the package sources and
tests found in the current directory and then runs the resulting
test binary. In this mode, caching (discussed below) is disabled.
After the package test finishes, go test prints a summary line
showing the test status ('ok' or 'FAIL'), package name, and elapsed
time.

The second, called package list mode, occurs when go test is invoked
with explicit package arguments (for example 'go test math', 'go
test ./...', and even 'go test .'). In this mode, go test compiles
and tests each of the packages listed on the command line. If a
package test passes, go test prints only the final 'ok' summary
line. If a package test fails, go test prints the full test output.
If invoked with the -bench or -v flag, go test prints the full
output even for passing package tests, in order to display the
requested benchmark results or verbose logging. After the package
tests for all of the listed packages finish, and their output is
printed, go test prints a final 'FAIL' status if any package test
has failed.

In package list mode only, go test caches successful package test
results to avoid unnecessary repeated running of tests. When the
result of a test can be recovered from the cache, go test will
redisplay the previous output instead of running the test binary
again. When this happens, go test prints '(cached)' in place of the
elapsed time in the summary line.

The rule for a match in the cache is that the run involves the same
test binary and the flags on the command line come entirely from a
restricted set of 'cacheable' test flags, defined as -benchtime, -cpu,
-list, -parallel, -run, -short, -timeout, -failfast, and -v.
If a run of go test has any test or non-test flags outside this set,
the result is not cached. To disable test caching, use any test flag
or argument other than the cacheable flags. The idiomatic way to disable
test caching explicitly is to use -count=1. Tests that open files within
the package's source root (usually $GOPATH) or that consult environment
variables only match future runs in which the files and environment
variables are unchanged. A cached test result is treated as executing
in no time at all,so a successful package test result will be cached and
reused regardless of -timeout setting.

In addition to the build flags, the flags handled by 'go test' itself are:

        -args
            Pass the remainder of the command line (everything after -args)
            to the test binary, uninterpreted and unchanged.
            Because this flag consumes the remainder of the command line,
            the package list (if present) must appear before this flag.

        -c
            Compile the test binary to pkg.test but do not run it
            (where pkg is the last element of the package's import path).
            The file name can be changed with the -o flag.

        -exec xprog
            Run the test binary using xprog. The behavior is the same as
            in 'go run'. See 'go help run' for details.

        -i
            Install packages that are dependencies of the test.
            Do not run the test.
            The -i flag is deprecated. Compiled packages are cached automatically.

        -json
            Convert test output to JSON suitable for automated processing.
            See 'go doc test2json' for the encoding details.

        -o file
            Compile the test binary to the named file.
            The test still runs (unless -c or -i is specified).

The test binary also accepts flags that control execution of the test; these
flags are also accessible by 'go test'. See 'go help testflag' for details.

For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.

See also: go build, go vet.
复制代码

go help testflag

$ go help testflag

The 'go test' command takes both flags that apply to 'go test' itself
and flags that apply to the resulting test binary.

Several of the flags control profiling and write an execution profile
suitable for "go tool pprof"; run "go tool pprof -h" for more
information. The --alloc_space, --alloc_objects, and --show_bytes
options of pprof control how the information is presented.

The following flags are recognized by the 'go test' command and
control the execution of any test:

        -bench regexp
            Run only those benchmarks matching a regular expression.
            By default, no benchmarks are run.
            To run all benchmarks, use '-bench .' or '-bench=.'.
            The regular expression is split by unbracketed slash (/)
            characters into a sequence of regular expressions, and each
            part of a benchmark's identifier must match the corresponding
            element in the sequence, if any. Possible parents of matches
            are run with b.N=1 to identify sub-benchmarks. For example,
            given -bench=X/Y, top-level benchmarks matching X are run
            with b.N=1 to find any sub-benchmarks matching Y, which are
            then run in full.

        -benchtime t
            Run enough iterations of each benchmark to take t, specified
            as a time.Duration (for example, -benchtime 1h30s).
            The default is 1 second (1s).
            The special syntax Nx means to run the benchmark N times
            (for example, -benchtime 100x).

        -count n
            Run each test, benchmark, and fuzz seed n times (default 1).
            If -cpu is set, run n times for each GOMAXPROCS value.
            Examples are always run once. -count does not apply to
            fuzz tests matched by -fuzz.

        -cover
            Enable coverage analysis.
            Note that because coverage works by annotating the source
            code before compilation, compilation and test failures with
            coverage enabled may report line numbers that don't correspond
            to the original sources.

        -covermode set,count,atomic
            Set the mode for coverage analysis for the package[s]
            being tested. The default is "set" unless -race is enabled,
            in which case it is "atomic".
            The values:
                set: bool: does this statement run?
                count: int: how many times does this statement run?
                atomic: int: count, but correct in multithreaded tests;
                        significantly more expensive.
            Sets -cover.

        -coverpkg pattern1,pattern2,pattern3
            Apply coverage analysis in each test to packages matching the patterns.
            The default is for each test to analyze only the package being tested.
            See 'go help packages' for a description of package patterns.
            Sets -cover.

        -cpu 1,2,4
            Specify a list of GOMAXPROCS values for which the tests, benchmarks or
            fuzz tests should be executed. The default is the current value
            of GOMAXPROCS. -cpu does not apply to fuzz tests matched by -fuzz.

        -failfast
            Do not start new tests after the first test failure.

        -fuzz regexp
            Run the fuzz test matching the regular expression. When specified,
            the command line argument must match exactly one package within the
            main module, and regexp must match exactly one fuzz test within
            that package. Fuzzing will occur after tests, benchmarks, seed corpora
            of other fuzz tests, and examples have completed. See the Fuzzing
            section of the testing package documentation for details.

        -fuzztime t
            Run enough iterations of the fuzz target during fuzzing to take t,
            specified as a time.Duration (for example, -fuzztime 1h30s).
                The default is to run forever.
            The special syntax Nx means to run the fuzz target N times
            (for example, -fuzztime 1000x).

        -fuzzminimizetime t
            Run enough iterations of the fuzz target during each minimization
            attempt to take t, as specified as a time.Duration (for example,
            -fuzzminimizetime 30s).
                The default is 60s.
            The special syntax Nx means to run the fuzz target N times
            (for example, -fuzzminimizetime 100x).

        -json
            Log verbose output and test results in JSON. This presents the
            same information as the -v flag in a machine-readable format.

        -list regexp
            List tests, benchmarks, fuzz tests, or examples matching the regular
            expression. No tests, benchmarks, fuzz tests, or examples will be run.
            This will only list top-level tests. No subtest or subbenchmarks will be
            shown.

        -parallel n
            Allow parallel execution of test functions that call t.Parallel, and
            fuzz targets that call t.Parallel when running the seed corpus.
            The value of this flag is the maximum number of tests to run
            simultaneously.
            While fuzzing, the value of this flag is the maximum number of
            subprocesses that may call the fuzz function simultaneously, regardless of
            whether T.Parallel is called.
            By default, -parallel is set to the value of GOMAXPROCS.
            Setting -parallel to values higher than GOMAXPROCS may cause degraded
            performance due to CPU contention, especially when fuzzing.
            Note that -parallel only applies within a single test binary.
            The 'go test' command may run tests for different packages
            in parallel as well, according to the setting of the -p flag
            (see 'go help build').

        -run regexp
            Run only those tests, examples, and fuzz tests matching the regular
            expression. For tests, the regular expression is split by unbracketed
            slash (/) characters into a sequence of regular expressions, and each
            part of a test's identifier must match the corresponding element in
            the sequence, if any. Note that possible parents of matches are
            run too, so that -run=X/Y matches and runs and reports the result
            of all tests matching X, even those without sub-tests matching Y,
            because it must run them to look for those sub-tests.

        -short
            Tell long-running tests to shorten their run time.
            It is off by default but set during all.bash so that installing
            the Go tree can run a sanity check but not spend time running
            exhaustive tests.

        -shuffle off,on,N
            Randomize the execution order of tests and benchmarks.
            It is off by default. If -shuffle is set to on, then it will seed
            the randomizer using the system clock. If -shuffle is set to an
            integer N, then N will be used as the seed value. In both cases,
            the seed will be reported for reproducibility.

        -timeout d
            If a test binary runs longer than duration d, panic.
            If d is 0, the timeout is disabled.
            The default is 10 minutes (10m).

        -v
            Verbose output: log all tests as they are run. Also print all
            text from Log and Logf calls even if the test succeeds.

        -vet list
            Configure the invocation of "go vet" during "go test"
            to use the comma-separated list of vet checks.
            If list is empty, "go test" runs "go vet" with a curated list of
            checks believed to be always worth addressing.
            If list is "off", "go test" does not run "go vet" at all.

The following flags are also recognized by 'go test' and can be used to
profile the tests during execution:

        -benchmem
            Print memory allocation statistics for benchmarks.

        -blockprofile block.out
            Write a goroutine blocking profile to the specified file
            when all tests are complete.
            Writes test binary as -c would.

        -blockprofilerate n
            Control the detail provided in goroutine blocking profiles by
            calling runtime.SetBlockProfileRate with n.
            See 'go doc runtime.SetBlockProfileRate'.
            The profiler aims to sample, on average, one blocking event every
            n nanoseconds the program spends blocked. By default,
            if -test.blockprofile is set without this flag, all blocking events
            are recorded, equivalent to -test.blockprofilerate=1.

        -coverprofile cover.out
            Write a coverage profile to the file after all tests have passed.
            Sets -cover.

        -cpuprofile cpu.out
            Write a CPU profile to the specified file before exiting.
            Writes test binary as -c would.

        -memprofile mem.out
            Write an allocation profile to the file after all tests have passed.
            Writes test binary as -c would.

        -memprofilerate n
            Enable more precise (and expensive) memory allocation profiles by
            setting runtime.MemProfileRate. See 'go doc runtime.MemProfileRate'.
            To profile all memory allocations, use -test.memprofilerate=1.

        -mutexprofile mutex.out
            Write a mutex contention profile to the specified file
            when all tests are complete.
            Writes test binary as -c would.

        -mutexprofilefraction n
            Sample 1 in n stack traces of goroutines holding a
            contended mutex.

        -outputdir directory
            Place output files from profiling in the specified directory,
            by default the directory in which "go test" is running.

        -trace trace.out
            Write an execution trace to the specified file before exiting.

Each of these flags is also recognized with an optional 'test.' prefix,
as in -test.v. When invoking the generated test binary (the result of
'go test -c') directly, however, the prefix is mandatory.

The 'go test' command rewrites or removes recognized flags,
as appropriate, both before and after the optional package list,
before invoking the test binary.

For instance, the command

        go test -v -myflag testdata -cpuprofile=prof.out -x

will compile the test binary and then run it as

        pkg.test -test.v -myflag testdata -test.cpuprofile=prof.out

(The -x flag is removed because it applies only to the go command's
execution, not to the test itself.)

The test flags that generate profiles (other than for coverage) also
leave the test binary in pkg.test for use when analyzing the profiles.

When 'go test' runs a test binary, it does so from within the
corresponding package's source code directory. Depending on the test,
it may be necessary to do the same when invoking a generated test
binary directly. Because that directory may be located within the
module cache, which may be read-only and is verified by checksums, the
test must not write to it or any other directory within the module
unless explicitly requested by the user (such as with the -fuzz flag,
which writes failures to testdata/fuzz).

The command-line package list, if present, must appear before any
flag not known to the go test command. Continuing the example above,
the package list would have to appear before -myflag, but could appear
on either side of -v.

When 'go test' runs in package list mode, 'go test' caches successful
package test results to avoid unnecessary repeated running of tests. To
disable test caching, use any test flag or argument other than the
cacheable flags. The idiomatic way to disable test caching explicitly
is to use -count=1.

To keep an argument for a test binary from being interpreted as a
known flag or a package name, use -args (see 'go help test') which
passes the remainder of the command line through to the test binary
uninterpreted and unaltered.

For instance, the command

        go test -v -args -x -v

will compile the test binary and then run it as

        pkg.test -test.v -x -v

Similarly,

        go test -args math

will compile the test binary and then run it as

        pkg.test math

In the first example, the -x and the second -v are passed through to the
test binary unchanged and with no effect on the go command itself.
In the second example, the argument math is passed through to the test
binary, instead of being interpreted as the package list.
复制代码

参考资料

Golang testing Doc

Add a test

how to write unit tests in go

why use testmain for testing in go

标签: 测试

上一篇:解析 Golang 测试（2）- gomock 下一篇:Linux grep 实战用法