• 0
  • 0
分享
  • Go-单元测试详解与代码——软件测试圈
  • TIMI 2021-07-23 10:37:57 字数 3354 阅读 1744 收藏 0

概述

常言道,不会测试的程序猿不是好的产品经理!!!现在越来越多测试和运维的工作也需要研发来做了,本篇文章就来讲讲Go的单元测试。

单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。简单说,就是将测试用例的运行结果与预期结果进行比较。

Go的单元测试

基础知识

Go有testing测试包,配合go test命令能够进行单元测试。

  1. 测试文件以_test.go结尾

  2. 在包目录内,所有以_test.go为后缀名的源代码文件都是go test测试的一部分,不会被go build编译到最终的可执行文件中。

  3. _test.go文件包含TestXxx函数

  4. 形参类型必须为*test.T

  5. PASS表示测试用例运行成功,FAIL表示失败

个人常用Fatalf,这里就来具体说一下,其他函数见参考的链接。

func (c *T) Logf(format string, args ...interface{})

Log 使用与 Printf 相同的格式化语法对它的参数进行格式化,然后将格式化后的文本记录到错误日志里面。 如果输入的格式化文本最末尾没有出现新行,那么将一个新行添加到格式化后的文本末尾。

  1. 对于测试来说,Logf 产生的格式化文本只会在测试失败或者设置了 -test.v 标志的情况下被打印出来;

  2. 对于基准测试来说,为了避免 -test.v 标志的值对测试的性能产生影响,Logf 产生的格式化文本总会被打印出来。

func (c *T) FailNow()

将当前测试标识为失败并停止执行该测试,在此之后,测试过程将在下一个测试或者下一个基准测试中继续。

FailNow 必须在运行测试函数或者基准测试函数的 goroutine 中调用,而不能在测试期间创建的 goroutine 中调用。调用 FailNow 不会导致其他 goroutine 停止。

func (c *T) Fatalf(format string, args ...interface{})

调用 Fatalf 相当于在调用 Logf 之后调用 FailNow 。 

快速入门

项目结构

learnGo

└── main

    ├── compute.go

    └── compute_test.go

compute.go

package main
 
import "errors"
 
func div(a,b int) (int,error) {
if b != 0{
return a/b,nil
} else{
return 0,errors.New("b is 0")
}
}

compute_test.go

package main
 
import "testing"
 
func TestDiv(t *testing.T)  {
res,_ := div(4,2)
want := 2
if res != want{
t.Fatalf("期待:%d ,实际结果:%d",want,res)
}
}

main目录下运行

go test -v

结果如下:

=== RUN   TestDiv
--- PASS: TestDiv (0.00s)
PASS
ok      learnGo/main    0.457s

以上我们就针对main包的compute.go文件进行了单元测试。

进阶

查看更多的选项,可使用

go help test
 
go help testflag

单个文件的测试

我们在main包中再添加str.go及str_test.go

str.go

package main
 
func getSub(str string,start,end int) string {
// 左闭右闭
if 0<=start&&start<end&&end<=len(str){
return str[start:end]
}else{
return ""
}
}

str_test.go

package main
 
import "testing"
 
func TestGetSub(t *testing.T)  {
astr := "lady_killer9"
// 包含开头
res1 := getSub(astr,0,4)
want1 := "lady"
// 包含结尾
res2 := getSub(astr,4,len(astr))
want2 := "_killer9"
// 范围错误
res3 := getSub(astr,1,len(astr)+1)
want3 := ""
if res1 != want1{
t.Errorf("期望:%s,实际结果:%s",want1,res1)
}
if res2 != want2{
t.Errorf("期望:%s,实际结果:%s",want2,res2)
}
if res3 != want3{
t.Errorf("期望:%s,实际结果:%s",want3,res3)
}
}

运行 go test -v,得到结果如下

=== RUN   TestDiv
--- PASS: TestDiv (0.00s)
=== RUN   TestGetSub
--- PASS: TestGetSub (0.00s)
PASS
ok      learnGo/main    0.446s

go test会运行所有的单元测试,有时候我们只想测试某个文件

如果只是运行一个测试文件,可添加参数

go test -v 测试文件 源文件

运行go test -v str_test.go str.go, 结果如下:

=== RUN   TestGetSub
--- PASS: TestGetSub (0.00s)
PASS
ok      command-line-arguments  0.619s

单个函数的测试

我们在compute.go中添加

func add(a,b int) int {
return a+b
}

在compute_test.go中添加

func TestAdd(t *testing.T)  {
a,b:=3,4
res := add(a,b)
want := 7
if res != want{
t.Fatalf("期待:%d,实际结果:%d",want,res)
}
}

由于对div函数未做改动,只想测试add函数,可以使用参数-test.run指定测试函数

go test -v -test.run 测试函数

运行 go test -v -test.run TestAdd 结果如下:

=== RUN   TestAdd
--- PASS: TestAdd (0.00s)
PASS
ok      learnGo/main    0.836s

单元测试覆盖率

测试应该全面,达到100%。

可以使用-cover参数

go test -cover

结果如下:

PASS
coverage: 85.7% of statements
ok      learnGo/main    0.505s

可以看到,测试的并不全面,指定测试文件来查看。

go test -cover compute_test.go compute.go
ok      command-line-arguments  0.314s  coverage: 75.0% of statements

观察发现,我们缺少了b为0的分支,修改TestDiv函数为

func TestDiv(t *testing.T)  {
res,_ := div(4,2)
want := 2
if res != want{
t.Fatalf("期待:%d,实际结果:%d",want,res)
}
res,_ = div(3,0)
want = 0
if res != want{
t.Fatalf("期待:%d,实际结果:%d",want,res)
}
}

测试后再看覆盖率,结果如下

PASS
coverage: 100.0% of statements
ok      learnGo/main    0.306s

作为开发,基本的单元测试就可以了,还可以去了解基准测试、性能测试、压力测试、黑盒测试等。


作者:lady_killer9

原文链接:https://blog.csdn.net/lady_killer9/article/details/116139322

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 我们在进行iOS Appium自动化测试的时候,会遇到环境配置、兼容使用问题,这里做个总结,以避免后续踩着这些坑。问题1. 提示no module “appium”解决:第1步,在终端输入命令:cd /usr/local/bin   pip3 install Appium-Python-Client因为appium默认装在了python2上。第2步,新建项目时要勾选。Inherit global site-packages和Make available to all projects。问题2. ...
            0 1 2098
            分享
          •   1、什么是白盒测试  定义:按照程序内部结构,逻辑驱动测试程序。  目的:检测产品内部动作是否按照设计说明书的规范进行,检验程序的每条路径是否都能按照预定要求进行工作。  对象:源程序。  用代码内部的分支,路径,条件,使程序设计的控制结构导出测试用例。  2、白盒测试方法分类  ①、静态测试  ②、动态测试  3、白盒测试的原则  ①、保证一个模块中所有路径至少被测试一次  ②、所有逻辑值都要测试真和假两种情况  ③、检查程序内部的数据结构是否有效  ④、检查上下边界及可操作范围内运行所有循环  4、白盒测试的类别  ①、软件共用问题的测试  ②、语言测试  ③、sql语句测试  ④、数...
            0 0 899
            分享
          • 接着上篇《深聊MySQL之:让orderby、Groupby查询速度飞起来(上)》我们今天继续讨论如何让orderby,groupby 的查询速度起飞 3、order by 优化我们了解了order by的原理,那么我们就来看看,优化order by 有什么技巧。3.1 添加合适索引3.1.1 排序字段添加索引①首先我们看下对 d 字段(没有索引)进行排序的执行计划:explain select d,id from t1 order by d;执行结果如下:发现使用的是 filesort(关注 Extra 字段)。...
            1 0 7455
            分享
          •   冒烟测试,刚进公司就接触到了。只是刚开始一直没有体会到冒烟的含义和精髓,一直以为是冒烟测试就是把待测产品的主要功能测试一下就行了。后面回想一下,不是那么回事的。  冒烟测试源自硬件行业,对一个硬件或者硬件组件改动后,直接给设备加电,看看设备会不会冒烟,没冒烟,就表示待测组件是通过了测试。  在软件开发过程中,一直有高内聚,低耦合这样的说法,各个功能模块之间的耦合还是存在的,因此一个功能的改动,还是会影响到其他功能模块。  因此在开发人员修复了先前测试中发现的bug后,想知道这个bug的修复是否会影响到其他功能模块,需要做的就是冒烟测试。  搞清楚冒烟测试的起源,冒烟测试的目的后,不难想到,...
            0 0 2606
            分享
          •   1. 测试稳定性问题  理想情况下,我们希望每一个失败的测试用例都是由真正的缺陷引起的。实际情况中,用例失败的原因大多是一些其他的原因:  ·某个服务的版本部署的不对  ·测试执行机的硬盘满了,因为上次运行时写的log没清掉  ·数据库里有脏数据  ·测试用例写得有问题  ·测试运行时有人手工执行了一次定时任务,把流水捞走了  ·消息串了  ...  每次排查都是一堆这种问题,时间久了,开发和测试同学也就疲了。有些同学对失败的用例草草看一眼,就说这是一个“环境问题”,不再排查下去了。如此一来,很多真正的缺陷就被漏过了。  2. 测试稳定性三板斧  如何治理测试稳定性问题?很多人会...
            11 12 2345
            分享
      • 51testing软件测试圈微信