golang test 某个函数 golang unit test

转载

AI大梦想家 2024-04-30 19:17:54

文章标签 golang test 某个函数 Go main函数测试用例 文章分类 架构后端开发

编写单元测试，运行时报下面的错误

haima@haima-PC:/media/haima/34E401CC64DD0E28/site/go/src/haimait/learn/base/cheshi01$ go test
go: cannot find main module, but found .git/config in /media/haima/34E401CC64DD0E28/site/go/src/haimait/learn
        to create a module there, run:
        cd ../.. && go mod init

出错原因是开启了go mod，但是没有初使化生成go.mod文件

解决办法1：关闭gomod

解决办法2：go mod init xx

https://zhuanlan.zhihu.com/p/417246469

main函数里测试

有时候，要测试一个函数是否功能正常，有时候我们会直接写在main函数里，然后通过log框架或者fmt直接打印信息，验证，下面给出一个例子

package main

import "fmt"

func main() {
    res := addUpper(10)
    fmt.Printf("返回值res:%v", res)
}

func add(n1 int , n2 int) int {
    return n1 + n2
}

func addUpper(n int) int {
    res := 0
    for i := 0 ; i <= n ; i++ {
        res += i
    }
    return res
}

这种方法对于单个文件，代码量不多，其实也是可以的，但是对于一个庞大的项目，这种方法就显得很麻烦，特别是生产，我们难道为了测试去更改main函数，然后再重启，显然是不合理的。然后所有的测试业务都写在main函数，不利于管理，代码量一多就会变得复杂

3、单位测试入门
testing是golang里的一个轻量级的测试框架，可以用于单位测试，也可以用于性能测试，程序员可以基于这个框架写相应的单位测试用例，然后通过日志打印等方式进行debug调试，定位排查问题

使用很容易，基于原来的文件，sample.go，新建一个sample_test.do的测试文件，注意，必须命名为*_test.do

package main

import (
    "testing"
)


func TestAdd(t *testing.T)  {
    res := add(1,2)
    if res != 3 {
        t.Fatalf("error res %v" , res)
    }
    t.Logf("success res %v" , res)
}

func TestAddUpper(t *testing.T)  {
    res := addUpper(10)
    if res != 55 {
        t.Fatalf("error res %v" , res)
    }
    t.Logf("success res %v" , res)
}

注意：

测试用例文件必须以_test.go结尾
测试用例函数必须以Test开头，一般是Test+被测试的函数名
测试函数形式参数必须是*testing.T
出现错误，t.Fatalf打印错误日志并退出程序
程序正常，t.Logf打印格式化的日志
测试单个文件，要加上测试的原文件go test -v sample_test.go sample.go
测试单个函数，加上方法名，go test -v sample_test.go TestAdd
运行测试用例命令
cmd > go test ：运行正确不打印日志，错误才会打印日志
cmd > go test -v ：运行错误或成功，都打印日志

Golang单元测试的基础今天就暂时到这里面，下面几个testing包的常用断言方法.

// 输出测试日志
t.Logf()
t.Logf()
// 标记错误，但仍然执行后面的语句
t.Fail()
// 获取是否当前用例是执行错误的
t.Failed()
// 错误输出，等于 t.Logf 再执行 t.Fail()
t.Errorf("%s", "run ErrorF")
// 标记函数错误，并中断后面的执行
t.FailNow()
// 致命错误输出，等同于调用了 t.Logf 然后调用 t.FailNow()
t.Fatalf("%s", "run Fatelf")

————————————————

go test [-c] [-i] [build flags] [packages] [flags for test binary]

测试覆盖率

测试覆盖率是你的代码被测试套件覆盖的百分比。通常我们使用的都是语句的覆盖率，也就是在测试中至少被运行一次的代码占总代码的比例。
Go提供内置功能来检查你的代码覆盖率。我们可以使用go test -cover来查看测试覆盖率。例如：

split $ go test -cover
PASS
coverage: 100.0% of statements
ok      github.com/Q1mi/studygo/code_demo/test_demo/split       0.005s

从上面的结果可以看到我们的测试用例覆盖了100%的代码。
Go还提供了一个额外的-coverprofile参数，用来将覆盖率相关的记录信息输出到一个文件。例如：

split $ go test -cover -coverprofile=c.out
PASS
coverage: 100.0% of statements
ok      github.com/Q1mi/studygo/code_demo/test_demo/split       0.005s

上面的命令会将覆盖率相关的信息输出到当前文件夹下面的c.out文件中，然后我们执行go tool cover -html=c.out，使用cover工具来处理生成的记录信息，该命令会打开本地的浏览器窗口生成一个HTML报告。

go test整个项目报错：

golang 运行 go test 时遇到报错 call has possible formatting directive %v 怎么解决

问题

Println call has possible formatting directive %v

go test 中不能使用 fmt.PrintLn(“%v”, v)

方案

使用 fmt.Printf(“%+v”, v)

fmt.Println("Hello, playground %d",i)
那么会出现warning:Println call has possible formatting directive %d Go vet exited.

fmt.Println doesn't do formatting things like %d. Instead, it uses the default format of its arguments, and adds spaces between them.

fmt.Println("Hello, playground",i) // Hello, playground 5
If you want printf style formatting, use fmt.Printf.

fmt.Printf("Hello, playground %d\n",i)
And you don't need to be particular about the type. %v will generally figure it out.

fmt.Printf("Hello, playground %v\n",i)
————————————————
原文链接：

Test注意要点

Go的test不会保证多个TestXxx顺序执行，但是通常会按顺序执行
使用t.Run来执行subtests可以做到控制test输出以及test的顺序

// 顺序执行
func TestPrintSub(t *testing.T){
    t.Run("a1",func(t *testing.T){fmt.Println("a1")})
    t.Run("a2",func(t *testing.T){fmt.Println("a2")})
    t.Run("a3",func(t *testing.T){fmt.Println("a3")})
}

使用TestMain作为初始化test,并且使用m.Run()来调用其他tests可以完成一些需要初始化操作的testing,
比如数据库连接，文件打开，Rest服务登录等

// TestMain
func TestMain(m *testing.M){
    fmt.Println("test main first")
    m.Run()
}

如果没有在TestMain中调用m.Run()则除了TestMain以外的其他tests都不好被执行

package split

import (
    "reflect"
    "testing"
)

func TestSplit(t *testing.T) {
    type args struct {
        s   string
        sep string
    }
    tests := []struct {
        name       string
        args       args
        wantResult []string
    }{
        // TODO: Add test cases. 
        {name: "test1",args: args{s:"a:b:c",sep: ":"},wantResult: []string{"a", "b", "c"}},
        {name: "test2",args: args{s:"a:b:c",sep: ","},wantResult: []string{"a:b:c"}},
        {name: "test3",args: args{s:"abcd",sep: "bc"},wantResult: []string{"a", "d"}},
        {name: "test4",args: args{s:"沙河有沙又有河",sep: "沙"},wantResult: []string{"河有", "又有河"}},
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            if gotResult := Split(tt.args.s, tt.args.sep); !reflect.DeepEqual(gotResult, tt.wantResult) {
                t.Errorf("Split() = %v, want %v", gotResult, tt.wantResult)
            }
        })
    }
}

链接：https://www.jianshu.com/p/3cf66a256d19

ubtests and Sub-benchmarks
T和B类型中的Run可以定义子测试和子benchmarks，不需要为sub们定义函数。This enables uses like table-driven benchmarks and creating hierarchical tests. It also provides a way to share common setup and tear-down code:（这个可以使用表驱动benchmark和层级式测试，也能提供公共setup和tear-down代码）

func TestFoo(t *testing.T) {
// <setup code>
t.Run("A=1", func(t *testing.T) { ... })
t.Run("A=2", func(t *testing.T) { ... })
t.Run("B=1", func(t *testing.T) { ... })
// <tear-down code>
}
运行测试时，可以-run和-bench flags设置运行那些测试：

go test -run '' # 运行所有测试
go test -run Foo # 运行一级测试，匹配 "Foo", 例如 "TestFooBar".
go test -run Foo/A= # 运行一级测试，匹配 "Foo", 运行二级测试，匹配 "A=".
go test -run /A=1 # 运行所有一级测试, 运行二级测试，匹配 "A=1".
子用例可以并行运行，父级仅在所有子用例运行完才完成。

func TestGroupedParallel(t *testing.T) {
for _, tc := range tests {
tc := tc // capture range variable
t.Run(tc.Name, func(t *testing.T) {
t.Parallel()
...
})
}
}
子测试间是并行的运行。

Main
有时需要在测试前或测试后有一些设置或tear-down的控制，或者控制那些代码需要在主线程运程，可以在一个文件内添加一个

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。