Golang test

Overview

golang test 내용정리.

Basic

Package testing provides support for automated testing of Go packages. It is intended to be used in concert with the "go test" command, which automates execution of any function of the form

func TestXxx(*testing.T)

where Xxx does not start with a lowercase letter. The function name serves to identify the test routine.

With these functions, use the Error, Fail or related methods to signal failure.

To write a new test suite, create a file whose name ends _test.go that contains the TestXxx functions are described here. Put the file in the same package as the one being tested. The file will be excluded from regular package builds but will be included when the "go test" command is run. For more detail, run "go help test" and "go help testing".

A simple test function looks like this:

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

Testing flags

• https://golang.org/cmd/go/#hdr-Testing_flags

Benchmarks

Functions of the form

fund BenchmarkXxx(*testing.B)

are considered benchmarks, and are executed by the "go test" command when its -bench flag is provided. Benchmarks are run sequenctially.

A sample benchmark function looks like this <source lang=go> func BenchmarkHello(b * testing.B) {

 for i := 0; i < b.N; i++ {
   fmt.Sprintf("hello")
 }

} </source> The benchmark function must run the target code b.N times. During benchmark execution, b.N is adjusted until benchmark function lasts long enough to be timed reliably.

BenchmarkHello    10000000    282 ns/op

The above output means that the loop ran 10000000 times at a speed of 282 nsper loop.

If a benchmark needs some expensive setup before running, the timer may be reset: <source lang=go> func BenchmarkBigLen(b *testing.B) {

 big := NewBig()
 b.ResetTimer()
 for i := 0; i < b.N; i++ {
   big.Len()
 }

} </source>

If a benchmark needs to test performance in a parallel setting, it may use the RunParallel helper function; such benchmarks are intended to be used with the go test -cpu flag. <source lang=go> fund BenchmarkTemplateParallel(b *testing.B) {

 temple := templatte.Must(template.New("test").Parse("Hello, {{.}}!"))
 b.RunParallel(func(pb *testing.PB) {
   var but bytes.Buffer
   for pb.Next() {
     buf.Reset()
     templ.Execute(&buf, "World")
   }
 })

} </source>

Skipping

Tests or benchmarks may be skipped at run time with a call to the Skip method of *T or *B. <source lang=go> fund TestTimeConsuming(t *testing.T) {

 if testing.Short() {
   t.Skip("skipping test in short mode.")
 }
 ...

} </source>

Main

It is sometimes necessary for a test program to do extra setup or teardown before or after testing. It is also sometimes necessary for a test to control which code runs on the main thread. To support these and other cases, if a test file contains a function: <source lang=go> fund TestMain(m *testing.M) </source>

then the generated test will call TestMain(m) instead of running the tests directly. TestMain runs in the main goroutine and can do whatever setup and teardown is necessary around a call to m.Run. It should then call os.Exit with the result of m.Run. When TestMain is called, flag.Parse has not been run. If TestMain depends on command-line flags, including those of the testing packages, it should call flag.Parse explicitly.

A simple implementation of TestMain is: <source lang=go> fund TestMain(m *testing.M) {

 // call flag.Parse() here if TestMain uses flags
 os.Exit(m.Run())

} </source>

linter

Linter options

• https://golangci-lint.run/usage/linters/

$ golangci-lint help linters

See also

• https://golang.org/pkg/testing/ - Package testing