十二、单元测试
- 传统方法的缺点分析
1 ) 不方便, 我们需要在main函数中去调用,这样就需要去修改main函数,如果现在项目正在运行,就可能去停止项目。
2 ) 不利于管理,因为当我们测试多个函数或者多个模块时,都需要写在main函数,不利于我们管理和清晰我们思路
3 ) 引出单元测试。->testing 测试框架 可以很好解决问题。
12.1 单元测试基本介绍
1 ) 确保每个函数是可运行,并且运行结果是正确的
2 ) 确保写出来的代码性能是好的,
3 ) 单元测试能及时的发现程序设计或实现的逻辑错误,使问题及早暴露,便于问题的定位解决,而性能测试的重点在于发现程序设计上的一些问题,让程序能够在高并发的情况下还能保持稳定
cal.go
package cal
//一个被测试函数
func addUpper(n int) int {
res := 0
for i := 1; i <= n - 1; i++ {
res += i
}
return res
}
//求两个数的查
func getSub(n1 int, n2 int) int {
return n1 - n2
}
cal_test.go
package cal
import (
"fmt"
"testing" //引入go 的testing框架包
)
//编写要给测试用例,去测试addUpper是否正确
func TestAddUpper(t *testing.T) {
//调用
res := addUpper(10)
if res != 55 {
//fmt.Printf("AddUpper(10) 执行错误,期望值=%v 实际值=%v\n", 55, res)
t.Fatalf("AddUpper(10) 执行错误,期望值=%v 实际值=%v\n", 55, res)
}
//如果正确,输出日志
t.Logf("AddUpper(10) 执行正确...")
}
func TestHello(t *testing.T) {
fmt.Println("TestHello被调用..")
}
特别说明 : 测试时,可能需要暂时退出 360 。(因为 360 可能会认为生成的测试用例程序是木马)
演示如何进行单元测试:
单元测试的运行原理示意图:
12.2 单元测试总结
1 ) 测试用例文件名必须以 _test.go 结尾。 比如 cal_test.go,cal 不是固定的。
2 ) 测试用例函数必须以Test开头,一般来说就是Test+被测试的函数名,比如TestAddUpper
3 ) TestAddUpper(t*tesingT) 的形参类型必须是 *testingT 【看一下手册】
4 ) 一个测试用例文件中,可以有多个测试用例函数,比如 TestAddUpper、TestSub
5 ) 运行测试用例指令
- ( 1 )cmd>gotest [如果运行正确,无日志,错误时,会输出日志]
- ( 2 )cmd>gotest-v [运行正确或是错误,都输出日志]
6 ) 当出现错误时,可以使用tFatalf 来格式化输出错误信息,并退出程序
7 ) tLogf 方法可以输出相应的日志
8 ) 测试用例函数,并没有放在main函数中,也执行了,这就是测试用例的方便之处[原理图]
9 ) PASS表示测试用例运行成功,FAIL 表示测试用例运行失败
10 ) 测试单个文件,一定要带上被测试的原文件 gotest-v cal_testgocalgo
11 )测试单个方法 gotest-v-testrun TestAddUpper