python中使用单元测试和代码覆盖率测试的一个小例子

因为大数据的关系,接触python,的确很棒的语言,简洁优雅。

今天下午给同事说要注意单元测试和代码覆盖率,于是随手举例,没想到演砸了,继而研究了一下,分享之。

首先进行的 run with coverrage 的结果,运行的是一个单元测试文件。(我们用的是pycharm)
可以看到,主程序 r2c1_mian.py 的覆盖率在 94%,还是很不错的。(当然程序相对简单)

屏幕快照 2015-12-09 17.11.28

看下面的这个函数,检查一个整数或者单词,设计上是2,然后前面单元测试也通过了,我于是说只要修改为3,那么这些业务逻辑就不对了,再跑单元测试就应该会有通不过的情况。

屏幕快照 2015-12-09 17.13.04

屏幕快照 2015-12-09 17.14.53

结果没想到,单元测试通过了,也就是这个业务逻辑是有问题的(代码没有贴全,后面会说到),因为单元测试中是有针对这类情况的断言测试的。

屏幕快照 2015-12-09 17.14.16

注意上面代码的第一个代码和下面的代码,左边都有绿色和红色,这就是前面覆盖率运行时候的标记,绿色表示单元测试执行到的代码,红色表示没有执行到。

上面的那个代码左边红色的恰恰是返回False的代码在单元测试中没有被测试到(这个test case是有的,其实是被其他代码执行到而跳过了),下面的代码是上面代码调用到的,从左边红颜色可以看到很明显,有一个内部的返回True和一个返回False都没有被测试到,所以需要修改单元测试代码,来保证测试覆盖率。

屏幕快照 2015-12-09 17.34.53

整个业务逻辑的修改过程不详细说了,后来发现不是单元测试用例问题,而是业务逻辑有问题,所以这部分代码重构了一下,再进行一次单元测试代码覆盖率测试,可以看到同样的代码左边全部是绿色了,也就是至少单元测试的代码都覆盖到了。(这样就比较心安)

屏幕快照 2015-12-09 18.36.24

然后运行刚才修改为3的代码部分(可以理解为修改错了,或者不小心改错了的模拟,如下单元测试告诉我们有一个test case无法通过,看列出的代码也的确是我们期望的错误。

屏幕快照 2015-12-09 18.40.14

最后是代码比较,为了这个本来想说明单元测试好处而做得演示结果真的发现错误然后重构了这部分逻辑的调整,用代码比较工具呈现的情况:

屏幕快照 2015-12-09 18.41.52

对于一个健壮的程序来说,单元测试还是需要的,对于单元测试来说,足够的test case很重要,而对于需要测试的代码的覆盖率检查也不能忽视。