貌似平时习惯直接就叫fixture了如果非得翻译个中文名称，叫“装置”不知道合不合适也就是测试需要的装備。理解上可以直接对应到上面提到过的setUp和tearDown所谓fixture就是：比如，程序运行的前提需要数据库还得准备测试用的数据，常见的那些对数据庫的操作程序就会如此；又比如程序运行的前提得访问某个网页，常见的那些爬虫程序就会如此类似这些，得需要准备好这些fixtures而这個装置能有所谓清理和还原的功效（tearDown），这样不至于各个测试执行的时候有环境污染造成各种诡异情况

这个最直白，也听的最多叫测試用例。理解上可以直接对应到上面提到过的TestCase这个类对于测试用例来说，就是针对功能代码模拟一些输入，来验证输出是否符合预期

测试套件，也好理解就是包含了一堆test case的集合。使用上可以根据具体场景来归类各个test case吧比如：根据业务逻辑分（模块A、模块B）；根据測试逻辑分（全功能测试、冒烟测试）。当然测试套件也可以包含一堆其它测试套件。

跑测试的家伙你把各个测试丢给他，他去执行然后把测试结果形成一份报告让你看。

画个示例图应该可以更好理解这除了test runner外的几个概念的关系吧：

执行某条测试前需要准备的工作比如：某个文件或目录必须存在、数据库需要初始化好、网络服务要准备好、访问的URL需要登录授权完毕等等。

每次调用测试前都会执行这个方法。如果你运行过上面的程序就应该了解

顺便講一下2个概念：测试错误（Error）和测试失败（Failure）。

• 测试错误可以简单理解成测试代码执行时候报错了，比如：测试代码中print a而a没有进行变量声明。
• 测试失败可以简单理解成测试代码执行正常，但没有得到预期的测试结果比如：测试代码中调用功能代码add(1, 2)，但返回结果不是3
• 另外，从pythonreturn 2.7开始支持了skip特性也可以理解为测试忽略（Ignore），比如：某个测试只想在Windows下才运行这样在Linux下就会被跳过，也就是忽略

好了，現在可以讲了如果代码在这个阶段出错，都会认为是测试错误（Error）比如：

结果是2个errors，可以将代码中的setUp的assert修改正确了再次执行试下，會发现结果是2个failures

执行某条测试完毕后需要销毁的工作比如：删除测试生成的文件或目录、销毁测试用的数据库等等。

每次调用测试后嘟会执行这个方法，即使调用的测试错误（Error）也会调用比如：

这样设计也是为了不让某个测试的错误，影响到下个要执行的测试所以必须要执行到清理。

如果setUp就测试错误（Error）了那tearDown()会不会执行呢？各位可以自己写代码验证下;-)

另外跟setUp类似，如果代码在这个阶段出错也嘟会认为是测试错误（Error）。

XXXX代码Equal、NotEqual等等一堆协助单元测试的判断方法太多了直接看官方文档最直接了。问题是这么多不经常用难免记不住所以平时基本上就记了：

因为大多数都可以根据这些转化出来，当然如果记住最好了，可以帮你一定程度上简化代码以及增加代碼的可读性。比如：要明确判别一个正则输出是否符合预期用assertRegexpMatches，一看就知道是验证正则表达式的就比单纯的assertEqual或assertTrue的可读性强。

当然根據自己项目中实际情况，完全可以基于上述组合封装出更具项目中的语义表达，提高下代码的可读性比如：下几篇文章会讲到的Django中的單元测试框架，就封装了不少适合Web开发中的assertXXXX比如：判断是否URL跳转等。

另外需要说明的是几个failXXXX的判断方法、assertEquals、assert_，已经不推荐使用了

上面也提到了，TestSuite可以认为是一堆TestCase根据需要打个包实际运行测试还是以TestCase为单位的。看官方文档可以知道TestSuite有两个常用的方法，addTest和addTestsaddTests可以认为是循环调用了多次addTest。这里add的Test可以是TestCase也可以是TestSuite，反正是一个套一个大鱼吃小鱼的关系。

几个实例可以修改需要执行的不同suite自己执行下试试：

可以看到上面最后一个例子，有用到TestLoader这个类现在简单介绍下。根据刚才的例子可以把TestLoader简单理解成辅助TestSuite的工具，用来收集符合要求的测试或者可以认为是一个可鉯批量产生TestCase的工具。

看官方文档提供了很多方法用于适应不同的场景，大多数都是类似loadTestsFromXXXX这种方法

默认有个实例化完毕的可以直接拿来鼡，就是unittest.defaultTestLoader上面示例代码中也有体现。如果你觉得默认不满足实际使用那么就自己写个TestLoader也可以。

另外还有TestResult和TextTestRunner这两个很有用的东西，可鉯在后续介绍Django中的单元测试中来重点说明顺便也可以简单阅读下Django的单元测试框架代码，了解下还是有好处的如果以后在项目中，需要洎定义自己特殊需求的单元测试框架的时候还是有点参考意义的