标签:blog http ar io color os 使用 sp for
单元测试的重要性就不多说了,可恶的是python中有太多的单元测试框架和工具,什么 unittest, testtools, subunit, coverage, testrepository, nose, mox, mock, fixtures, discover,再加上setuptools, distutils等等这些,先不说如何写单元测试,光是怎么运行单元测试就有N多种方法,再因为它是测试而非功能,是很多人没兴趣触及的东西。但是作为 一个优秀的程序员,不仅要写好功能代码,写好测试代码一样的彰显你的实力。如此多的框架和工具,很容易让人困惑,困惑的原因是因为并没有理解它的基本原 理,如果一些基本的概念都不清楚,怎么能够写出思路清晰的测试代码?
今天的主题就是unittest,作为标准python中的一个模块,是其它框架和工具的基础,参考资料是它的官方文档:http://docs.python.org/2.7/library/unittest.html和源代码,文档已经写的非常好了,我在这里记录的主要是它的一些重要概念、关键点以及可能会碰到的一些坑,目的在于对unittest加深理解,而不是停留在泛泛的表面层上。
unittest是一个python版本的junit,junit是java中的单元测试框架,对java的单元测试,有一句话很贴切:Keep the bar green,相信使用eclipse写过java单元测试的都心领神会。unittest实现了很多junit中的概念,比如我们非常熟悉的test case, test suite等,总之,原理都是相通的,只是用不同的语言表达出来。
在文档的开篇就介绍了unittest中的4个重要的概念:test fixture, test case, test suite, test runner,我觉得只有理解了这几个概念,才能真正的理解单元测试的基本原理,下面就主要围绕这几个概念来展开这篇文章。
首先通过查看unittest的源码,来看一下这几个概念,以及他们之间的关系,他们是如何在一起工作的,其静态类图如下:
这样整个流程就清楚了,首先是要写好TestCase,然后由TestLoader加载TestCase到TestSuite,然后由 TextTestRunner来运行TestSuite,运行的结果保存在TextTestResult中,整个过程集成在unittest.main模 块中。
现在已经涉及到了test case, test suite, test runner这三个概念了,还有test fixture没有提到,那什么是test fixture呢??在TestCase的docstring中有这样一段话:
Test authors should subclass TestCase for their own tests. Construction and deconstruction of the test‘s environment (‘fixture‘) can be implemented by overriding the ‘setUp‘ and ‘tearDown‘ methods respectively.
可见,对一个测试用例环境的搭建和销毁,是一个fixture,通过覆盖TestCase的setUp()和tearDown()方法 来实现。这个有什么用呢?比如说在这个测试用例中需要访问数据库,那么可以在setUp()中建立数据库连接以及进行一些初始化,在tearDown() 中清除在数据库中产生的数据,然后关闭连接。注意tearDown的过程很重要,要为以后的TestCase留下一个干净的环境。关于fixture,还 有一个专门的库函数叫做fixtures,功能更加强大,以后会介绍到。
至此,概念和流程基本清楚了,下面通过简单的例子再来实践一下,就拿unittest文档上的例子吧:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
import random import unittest class TestSequenceFunctions(unittest.TestCase): def setUp( self ): self .seq = range ( 10 ) def test_shuffle( self ): # make sure the shuffled sequence does not lose any elements random.shuffle( self .seq) self .seq.sort() self .assertEqual( self .seq, range ( 10 )) # should raise an exception for an immutable sequence self .assertRaises(TypeError, random.shuffle, ( 1 , 2 , 3 )) def test_choice( self ): element = random.choice( self .seq) self .assertTrue(element in self .seq) def test_sample( self ): with self .assertRaises(ValueError): random.sample( self .seq, 20 ) for element in random.sample( self .seq, 5 ): self .assertTrue(element in self .seq) if __name__ = = ‘__main__‘ : unittest.main() |
TestSequenceFunctions继承自unittest.TestCase,重写了setUp()方法,并且定义了三个以‘test‘ 开头的方法,那这个TestSequenceFunctions类到底是个什么呢?它是一个测试用例,还是三个测试用例?说是三个测试用例的话,它本身继 承自TestCase,说是一个测试用例的话,里面又有三个test_*()方法,明显是三个测试用例。其实,我们只要看一些TestLoader是如何 加载测试用例的,就一清二楚了,在loader.TestLoader类中有一个loadTestsFromTestCase()方法:
1
2
3
4
5
6
7
8
9
10
|
def loadTestsFromTestCase( self , testCaseClass): """Return a suite of all tests cases contained in testCaseClass""" if issubclass (testCaseClass, suite.TestSuite): raise TypeError( "Test cases should not be derived from TestSuite." \ " Maybe you meant to derive from TestCase?" ) testCaseNames = self .getTestCaseNames(testCaseClass) if not testCaseNames and hasattr (testCaseClass, ‘runTest‘ ): testCaseNames = [ ‘runTest‘ ] loaded_suite = self .suiteClass( map (testCaseClass, testCaseNames)) return loaded_suite |
getTestCaseNames()是从TestCase这个类中找所有以“test”开头的方法,然后注意第9行,在构造TestSuite对 象时,其参数使用了一个map方法,即对testCaseNames中的每一个元素,使用testCaseClass为其构造对象,其结果是一个 TestCase的对象集合,可以用下面的代码来分步说明:
1
2
3
4
|
testcases = [] for name in testCaeNames: testcases.append(TestCase(name)) loaded_suite = self .suiteClass( tuple (testcases)) |
可见,对每一个以test开头的方法,都为其构建了一个TestCase对象,值得注意的是,如果没有定义test开头的方法,而是将 测试代码写到了一个名为runTest的方法中,那么会为该runTest方法构建TestCase对象,如果定义了test开头的方法,就会忽略 runTest方法。
至此,基本就清楚了,每一个以test开头的方法,都会为其构建TestCase对象,也就是说TestSequenceFunctions类中其 实定义了三个TestCase,之所以写成这样,是为了方便,因为这几个测试用例的fixture是相同的,如果每一个测试用例单独写成一个 TestCase的话,会有很多的冗余代码。
明白了这些,文档就可以很轻松的看懂了,至于怎么运行测试用例,以及其他的内容,直接看文档吧。
标签:blog http ar io color os 使用 sp for
原文地址:http://www.cnblogs.com/jane0912/p/4169463.html