热身

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。Golang当然也有自带的测试包testing，使用该包可以进行自动化的单元测试，输出结果验证。

如果之前从没用过golang的单元测试的话，可以输入命令 go help test，看看官方的介绍。 这里只打印一些关键信息：

E:\mygolandproject\MyTest>go help test
usage: go test [build/test flags] [packages] [build/test flags & 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.
// ......
The go tool will ignore a directory named "testdata", making it available
to hold ancillary data needed by the tests.
// ......
'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, and
example functions. See 'go help testfunc' for more.
// ......

再执行 go help testfunc 看看

E:\mygolandproject\MyTest1>go help testfunc
The 'go test' command expects to find test, benchmark, and example functions
in the "*_test.go" files corresponding to the package under test.

A test function is one named TestXxx (where Xxx does not start with a
lower case letter) and should have the signature,

        func TestXxx(t *testing.T) { ... }
// ......
See the documentation of the testing package for more information.

现在应该清楚了，要编写一个测试套件，首先需要创建一个名称以 _test.go 结尾的文件，该文件包含 TestXxx 函数：

func TestXxx(*testing.T)    // Xxx 可以是任何字母数字字符串，但是第一个字母不能是小写字母。

go test的基本格式是：

go test [build/test flags] [packages] [build/test flags & test binary flags]

执行 go test 命令后，就会在指定的包下寻找 *_test.go 文件中的 TestXxx 函数来执行。 除了一些可选的 flags 外，需要注意一下 packages 的填写。该*_test.go测试文件必须要与待测试的文件置于同一包下，执行 go test 或 go test . 或 go test ./xxx_test.go 都可以运行测试套。测试文件不会参与正常源码编译，不会被包含到可执行文件中。

go test 命令会忽略 testdata 目录，该目录是用来保存测试需要用到的辅助数据。

执行完成后就会打印结果信息：

ok   archive/tar   0.011s
FAIL archive/zip   0.022s
...

单元测试

要测试的代码：

func Fib(n int) int {
    if n < 4 {
        return n      
    }
    return Fib(n-1) + Fib(n-2)
}

测试代码：

func TestFib(t *testing.T) {
    var (
       in       = 7
       expected = 13
    )
    actual := Fib(in)
    fmt.Println(actual)
    if actual != expected {
       // Errorf()函数是单元测试中用于打印格式化的错误信息。
       t.Errorf("Fib(%d) = %d; expected %d", in, actual, expected)
    }
}

执行结果如下：

E:\myGolandProject\MyTest>go test
PASS
ok      gin/MyTest     0.670s

把 expected 改为14，执行结果如下：

E:\myGolandProject\MyTest>go test
--- FAIL: TestFib (0.00s)
    first_test.go:15: Fib(7) = 13; expected 14
FAIL
exit status 1
FAIL    gin/MyTest     0.585s

测试讲究 case 覆盖，按上面的方式，当我们要覆盖更多 case 时，显然通过修改代码的方式很笨拙。这时我们可以采用 Table-Driven 的方式写测试，标准库中有很多测试是使用这种方式写的。

func TestFib(t *testing.T) {
    var fibTests = []struct {
        in       int // input
        expected int // expected result
    }{
        {1, 1},
        {2, 1},
        {3, 2},
        {4, 3},
        {5, 5},
        {6, 8},
        {7, 13},
    }

    for _, tt := range fibTests {
        actual := Fib(tt.in)
        if actual != tt.expected {
            t.Errorf("Fib(%d) = %d; expected %d", tt.in, actual, tt.expected)
        }
    }
}

上面例子中，即使其中某个 case 失败，也不会终止测试执行。

不过可能有小伙伴会觉得为了测试一个简单的函数就要写这么长一段代码，太麻烦了吧！

不用担心，Goland已经具备了一键生成单元测试代码的功能。

如图所示，光标置于函数名之上，右键选择Generate，我们可以选择生成整个package、当前file或者当前选中函数的测试代码。以当前选中函数为例，Goland会自动在当前目录下生成测试文件，内容如下：

func TestFib(t *testing.T) {
   type args struct {
      n int
   }
   tests := []struct {
      name string
      args args
      want int
   }{
      // TODO: Add test cases.
   }
   for _, tt := range tests {
      t.Run(tt.name, func(t *testing.T) {
         if got := Fib(tt.args.n); got != tt.want {
            t.Errorf("Fib() = %v, want %v", got, tt.want)
         }
      })
   }
}

我们只需要把测试用例添加到TODO中即可。

这里有个坑需要注意一下，假设原文件是Fib.go，生成的测试文件是Fib_test.go。如果我们直接构造测试用例，然后运行go test ./Fib_test.go的话会报如下错误：

# command-line-arguments [command-line-arguments.test]
.\Fib_test.go:26:14: undefined: Fib
FAIL    command-line-arguments [build failed]
FAIL

解决方法：测试单个文件，需要要带上被测试的原文件，如果原文件有其他引用，也需一并带上。 将go test ./Fib_test.go改为go test ./Fib.go ./Fib_test.go即可

继续探索

到这里已经基本介绍了 Golang单元测试的基本流程。但是还有个疑问没解开，就是*testing.T

函数TestFib(t *testing.T)中的入参 *testing.T 是个啥东西？我们进去源码瞧瞧

// T is a type passed to Test functions to manage test state and support formatted test logs.
//
// A test ends when its Test function returns or calls any of the methods
// FailNow, Fatal, Fatalf, SkipNow, Skip, or Skipf. Those methods, as well as
// the Parallel method, must be called only from the goroutine running the
// Test function.
//
// The other reporting methods, such as the variations of Log and Error,
// may be called simultaneously from multiple goroutines.
type T struct {
   common
   isParallel bool
   context    *testContext // For running tests and subtests.
}

可以看到，T是传递给Test函数的类型，用于管理测试状态并支持格式化的测试日志。测试日志会在执行测试的过程中不断累积，并在测试完成时转储至标准输出。

当测试函数返回时，或者当测试函数调用 FailNow、 Fatal、Fatalf、SkipNow、Skip、Skipf 中的任意一个时，则宣告该测试函数结束。跟 Parallel 方法一样，以上提到的这些方法只能在运行测试函数的 goroutine 中调用。

至于其他报告方法，比如 Log 以及 Error 的变种， 则可以在多个 goroutine 中同时进行调用。

T 类型内嵌了 common 类型，common 提供这一系列方法，我们经常会用到的（注意，这里说的测试中断，都是指当前测试函数，并不是中断整个测试文件的执行）：

1. 当我们遇到一个断言错误的时候，标识这个测试失败，会使用到：

Fail : 测试失败，测试继续，也就是之后的代码依然会执行
FailNow : 测试失败，测试函数中断

在 FailNow 方法实现的内部，是通过调用 runtime.Goexit() 来中断测试的。

1. 当我们遇到一个断言错误，只希望跳过这个错误并中断，但是不希望标识测试失败，会使用到：

SkipNow : 跳过测试，测试中断

在 SkipNow 方法实现的内部，是通过调用 runtime.Goexit() 来中断测试函数的。

1. 当我们只希望打印信息，会用到 :

Log : 输出信息
Logf : 输出格式化的信息

注意：默认情况下，单元测试成功时，它们打印的信息不会输出，可以通过加上 -v 选项，输出这些信息。但对于基准测试，它们总是会被输出。

1. 当我们希望跳过这个测试函数，并且打印出信息，会用到：

Skip : 相当于 Log + SkipNow
Skipf : 相当于 Logf + SkipNow

1. 当我们希望断言失败的时候，标识测试失败，并打印出必要的信息，但是测试函数继续执行，会用到：

Error : 相当于 Log + Fail
Errorf : 相当于 Logf + Fail

1. 当我们希望断言失败的时候，标识测试失败，打印出必要的信息，但中断测试函数，会用到：

Fatal : 相当于 Log + FailNow
Fatalf : 相当于 Logf + FailNow

接着来看一下runtime.Goexit()的定义：

// Goexit terminates the goroutine that calls it. No other goroutine is affected.
// Goexit runs all deferred calls before terminating the goroutine. Because Goexit
// is not a panic, any recover calls in those deferred functions will return nil.
//
// Calling Goexit from the main goroutine terminates that goroutine
// without func main returning. Since func main has not returned,
// the program continues execution of other goroutines.
// If all other goroutines exit, the program crashes.
func Goexit(){
    ...
}

函数头第一句注释就说明了Goexit会终止调用它的goroutine。那问题来了，当某个测试函数断言失败调用FailNow的时候，为什么后面的测试代码还可以执行呢？难道不是一个Goroutine执行完整个测试文件吗？(菜鸡的我刚开始确实是这么想的..)。其实答案就在testing包！

testing包中有一个Runtest函数：

// RunTests is an internal function but exported because it is cross-package;
// it is part of the implementation of the "go test" command.
func RunTests(matchString func(pat, str string) (bool, error), tests []InternalTest) (ok bool) {
   var deadline time.Time
   if *timeout > 0 {
      deadline = time.Now().Add(*timeout)
   }
   ran, ok := runTests(matchString, tests, deadline)
   if !ran && !haveExamples {
      fmt.Fprintln(os.Stderr, "testing: warning: no tests to run")
   }
   return ok
}

• 原来Runtest函数就是go test命令的实现！
• tests []InternalTest这个切片入参就是保存着测试文件中所有的测试函数
• 调用了runTests，tests切片入参也被传了进去

再看看runTests函数内部实现，我把其他的实现细节屏蔽了：

func runTests(matchString func(pat, str string) (bool, error), tests []InternalTest, deadline time.Time) (ran, ok bool) {
  // ......
         tRunner(t, func(t *T) {
            for _, test := range tests {
               t.Run(test.Name, test.F)
            }
         })
  // ......
}

果然是这样，遍历了tests切片，对每个测试函数都调用了Run这个方法

// Run runs f as a subtest of t called name. It runs f in a separate goroutine
// and blocks until f returns or calls t.Parallel to become a parallel test.
// Run reports whether f succeeded (or at least did not fail before calling t.Parallel).
//
// Run may be called simultaneously from multiple goroutines, but all such calls
// must return before the outer test function for t returns.
func (t *T) Run(name string, f func(t *T)) bool {
   atomic.StoreInt32(&t.hasSub, 1)
   testName, ok, _ := t.context.match.fullName(&t.common, name)
   if !ok || shouldFailFast() {
      return true
   }
   // Record the stack trace at the point of this call so that if the subtest
   // function - which runs in a separate stack - is marked as a helper, we can
   // continue walking the stack into the parent test.
   var pc [maxStackLen]uintptr
   n := runtime.Callers(2, pc[:])
   t = &T{
      common: common{
         barrier: make(chan bool),
         signal:  make(chan bool, 1),
         name:    testName,
         parent:  &t.common,
         level:   t.level + 1,
         creator: pc[:n],
         chatty:  t.chatty,
      },
      context: t.context,
   }
   t.w = indenter{&t.common}

   if t.chatty != nil {
      t.chatty.Updatef(t.name, "=== RUN   %s\n", t.name)
   }
   // Instead of reducing the running count of this test before calling the
   // tRunner and increasing it afterwards, we rely on tRunner keeping the
   // count correct. This ensures that a sequence of sequential tests runs
   // without being preempted, even when their parent is a parallel test. This
   // may especially reduce surprises if *parallel == 1.
   go tRunner(t, f)
   if !<-t.signal {
      // At this point, it is likely that FailNow was called on one of the
      // parent tests by one of the subtests. Continue aborting up the chain.
      runtime.Goexit()
   }
   return !t.failed
}

答案就在这里，对于每个f，也就是测试函数，都起了一个新的Goroutine来执行！所以当某个测试函数断言失败调用FailNow的时候，后面的测试代码是可以执行的，因为每个TestXxx函数跑在不同的Goroutine上。

扩展

在Go1.17中，给go test新增了一个-shuffle选项，shuffle是洗牌的意思，顾名思义就是TestXxx测试方法的执行顺序被打乱了。

切换到Go1.17，执行go help testflag，找到-shuffle的描述

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

-shuffle默认是off，设置为on就会打开洗牌。

写个简单Demo验证一下：

import (
   "testing"
)

func TestFunc1(t *testing.T) {
   t.Logf("1")
}

func TestFunc2(t *testing.T) {
   t.Logf("2")
}

func TestFunc3(t *testing.T) {
   t.Logf("3")
}

func TestFunc4(t *testing.T) {
   t.Logf("4")
}

执行结果如下：

E:\myGolandProject\MyTest>go test -v -shuffle=on .
-test.shuffle 1637545619604654100
=== RUN   TestFunc4
    fib2_test.go:20: 4
--- PASS: TestFunc4 (0.00s)
=== RUN   TestFunc3
    fib2_test.go:16: 3
--- PASS: TestFunc3 (0.00s)
=== RUN   TestFunc1
    fib2_test.go:8: 1
--- PASS: TestFunc1 (0.00s)
=== RUN   TestFunc2
    fib2_test.go:12: 2
--- PASS: TestFunc2 (0.00s)
PASS
ok      command-line-arguments  0.025s

如果按照某种测试顺序会导致错误的话，那么这种错误是很难定位的，这时候就可以利用-shuffle选项来解决这种问题

参考：www.cnblogs.com/Detector/p/…