Go unit test, 单体测试

Go unit test, 单体测试 执行某一个测试文档 go test foo_test.go go test -v foo_test.go // 强制 go test 运行一次,不使用缓存, 在配置了 -count 参数的情况下,go test 会忽略缓存 // -count, 执行测试的次数 go test -count=1 foo_test.go # 执行某一个文件中的某一个或几个函数 go test path/to/foo_test.go -run "^TestFunc0$" go test 会默认缓存测试运行的结果(Test Cache),缓存判断的依据是: 测试本身的代码(如 *_test.go 文件) 测试依赖的源文件是否发生变更 测试的相关环境参数是否发生变化(环境变量、命令参数等) Go 语言推荐测试文件和源代码文件放在一块,测试文件以 _test.go 结尾。比如,当前 package 有 calc.go 一个文件,我们想测试 calc.go 中的 Add 和 Mul 函数,那么应该新建 calc_test.go 作为测试文件。 calc_test.go package main import "testing" func TestAdd(t *testing.T) { t.Log("test foo") if ans := Add(1, 2); ans != 3 { t.Errorf("1 + 2 expected be 3, but %d got", ans) } if ans := Add(-10, -20); ans != -30 { t.Errorf("-10 + -20 expected be -30, but %d got", ans) } } 测试用例名称一般命名为 Test 加上待测试的方法名。 测试用的参数有且只有一个, 在这里是 t *testing.T ...

2016-07-13 · 4 min · 644 words · -

测试覆盖

测试覆盖 传统的测试覆盖方法常见的有以下几种: 函数覆盖 (Function Coverage) 语句覆盖 (Statement Coverage) 决策覆盖 (Decision Coverage) 条件覆盖 (Condition Coverage) 还有一些其他覆盖方法,如Modified Condition/Decision Coverage,就不在这里讨论了。 函数覆盖: 顾名思义,就是指这个函数是否被测试代码调用了。以下面的代码为例,对函数foo要做到覆盖,只要一个测试——如assertEquals(2, foo(2, 2))——就可以了。如果连函数覆盖都达不到,那应该想想这个函数是否真的需要了。如果需要的话,那又为什么写不了一个测试呢? 语句覆盖: (也称行覆盖) ,指的是某一行代码是否被测试覆盖了。同样的代码要达到语句覆盖也只需要一个测试就够了,如assertEquals(2, foo(2, 2))。但是,如果把测试换成assertEquals(0, foo(2, -1)),那就无法达到所有行覆盖的效果了。通常这种情况是由于一些分支语句导致的,因为相应的问题就是"那行代码 (以及它所对应的分支) 需要吗?",或者"用什么测试可以覆盖那行代码所代表的分支呢?"。 **决策覆盖: **指的是某一个逻辑分支是否被测试覆盖了。如我上面所说,语句覆盖通常和决策覆盖有关系。还是以上面的代码为例,要达到所有的决策覆盖 (即那个if语句为真和假的情况至少出现一次) ,我们需要至少两个测试,如assertEquals(2, foo(2, 2))和assertEquals(0, foo(-1, 2))。如果有一个逻辑分支没有被覆盖 (比如只有测试assertEquals(2, foo(2, 2))) ,那么我们应该问和上面"语句覆盖"小节中相似的问题。 条件覆盖:指的是分支中的每个条件 (即与,或,非逻辑运算中的每一个条件判断) 是否被测试覆盖了。之前的代码要达到全部的条件覆盖 (也就是x>0和y>0这两个条件为真和假的情况均至少出现一次) 需要更多的测试,如assertEquals(2, foo(2, 2)),assertEquals(2, foo(2, -1))和assertEquals(2, foo(-1, -1))。如果有一个条件分支没有被覆盖 (比如缺少测试assertEquals(2, foo(-1, -1))) ,那么大家应该想想"那个条件判断是否还需要呢?",或者"用什么测试可以覆盖那个条件所对应的逻辑呢?"。 通过上面对几种传统的测试覆盖方法的介绍,大家不难发现,这些方法的确可以帮我们找到一些显而易见的代码冗余或者测试遗漏的问题。不过,实践证明,这些传统的方法只能产生非常有限的"学习"代码和测试中问题的机会。很多代码和测试的问题即使在达到100%覆盖的情况下也无法发现。然而,我接下来要介绍的"代码变异测试"这种方法则,它可以很好的弥补传统方法的缺点,产生更加有效的"学习"机会。 http://www.infoq.com/cn/articles/test-coverage-rate-role

2013-12-09 · 1 min · 59 words · -