Python接口自动化学习

uinittest单元测试框架是受到JUnit的启发，unittest支持测试自动化，共享测试的设置和关闭代码，将测试聚合到集合中以及测试与报告框架的独立性。

fixture表示测试之前的准备工作和清除工作。例如，创建临时或代理数据库，目录或启动服务器进程。

test case 是测试的各个单元。它检查对一组特定输入的特定响应，unittest提供了一个基类，TestCase用来创建testcase。

test suite是test case的合集，通常用test suite将test case汇总然后一起执行。

test runner是一个执行器，它可以执行case 并提供结果给用户。可以提供图形界面、文本界面或者返回值表示测试结果。

举例说明 unittest模块提供了丰富的工具来构建和运行测试，本节演示了工具的一小部分足以满足大多数用户的需求。

通过子类创建测试用例unittest.TestCase。执行测试的方法命名需要test开头。 每个testcase都是用assertEqual()来检查预期结果。assertTrue、assertFalse、assertRaise验证是否引发了特定的异常。使用这些方法代替assert语句，测试运行程序可以累积所以测试结果并生成测试报告。 setUp()和tearDown允许你定义将在每次测试方法前后执行的指令， 运行结果：

将-v选项传递给测试脚本将指示unittest.main() 启用更高级别的详细程度

unittest支持以下命令行选项：

在测试运行期间，将缓冲标准输出和标准错误流，通过测试期间的输出将被丢弃，在测试失败或错误时通常会回显输出添加到失败消息中。

在测试运行期间执行conrol -C ，等待当前测试结束，然后报告到目前为止的所有结果。再次按control -C引发正常KeyboardInterrupt异常。

在第一个错误或失败时停止测试运行。

仅运行与模式或字符串匹配的测试方法和类。此选项可以多次使用，在这种情况下，将包括与给定模式匹配的所有测试用例。

在回溯中显示局部变量。 新的3.2版本：命令行选项-b，-c并-f添加。 3.5版的新功能：命令行选项–locals。 3.7版的新功能：命令行选项-k。 命令行还可以用于测试发现，运行项目中的所有测试或仅运行子集。

3.2版本的新功能 unittest支持简单的测试发现，为了兼容test discovery，所有测试文件必须是可从项目顶层目录导入模块或包（包括名称空间包） Test Discovery在TestLoader.discover()中实现，但是仍能用于命令行模式。用法：

cd project_directory python -m unittest discover

注意：如果要传递参数Test Discovery，则必须显示使用全命令。python -m unittestpython -m unittest discoverdiscover

该discover子命令具有以下选项：

-v, --verbose 详细输出

-s, --start-directory directory 开始发现的目录（.默认）

-p, --pattern pattern 模式以匹配测试文件（test*.py默认）

-t, --top-level-directory directory 项目的顶层目录（默认为起始目录）

的-s，-p和-t选项可以作为的顺序位置参数传递。以下两个命令行是等效的：

python -m unittest discover -s project_directory -p “_test.py" python -m unittest discover project_directory "_test.py”

除了作为路径外，还可以传递软件包名称，例如 myproject.subpackage.test，作为起始目录。然后，讲提供您提供的软件包名称，并将其在文件系统上的位置用作起始目录。

注意：Test Discovery通过导入来加载测试，一旦Test Discovery从开始目录中找到所有测试文件，就可以指定将路径转换为要导入的程序包名称。例如，foo/bar/baz.py将导入为foo.bar.baz。

如果在公共的包并且使用test discovery去加载该包的另一个不同副本，那么就会引发异常，导致discovery退出。 如果提供一个起始目录作为包名称而不是提供一个路径作为目录，那么discovery就会认为所有位置的文件都是你需要导入的（包括中间路径），这样就不会报错。

测试模块和包通过load_tests协议以指定的方式加载测试和运行discover。

单元测试的基本构建模块是test cases，单一的测试逻辑场景并检查其正确性。在unittest中，test case被unittest.TestCase的实例表示。要制作自己的测试用例，必须编写TestCase的子类或者使用FunctionTestCase.

TestCase实例的测试代码必须是完整且是自包含的，来使他可以独立运行或任意数量的其他测试用例任意组合运行。 最简单的TestCase子类将简单实现一个测试方法（名称以开头的方法test），执行特定的代码：

注意：为了测试某些内容，我们使用基类assert()的方法。如果测试失败，就会抛出一个异常并且显示具体信息，unittest就认为该测试失败。异常都会被认为失败。*

测试比较多的时候，测试的初始化会显得重复冗余复杂，我们可以将这部分单独拿出来，实现setUp()的方法，测试框架会自动的在每个测试执行前执行该方法。

注意：通过根据字符串的内置顺序对测试方法名称进行排序，确定测试的运行顺序。

如果在setUp()测试运行时该方法引发异常，则框架将认为该测试已发生错误，并且该测试方法将不会执行。 同样我们可以提供一种tearDown()在测试方法运行后进行整理的方法。

如果setUp()成功，测试方法不管是成功或失败，tearDown()都会运行。 对于测试代码来讲，这样的工作机制称为Test Fixture。一个新的TestCase实例被当做 Test Fixture创建，用于执行每个测试方法。也就是说，TestCase.setUp、TestCase.tearDown和TestCase.__init__会在每个用例执行运行一次。

建议使用TestCase去根据测试的特性对其进行分组。unittest提供一个一个机制：测试套件（test suit），由unittest的TestSuite类实现。如果测试很多的话，调用unittest.main方法可以手机模型中所有的测试方法并执行。 自定义套件：

可以将测试用例或者测试套件写在被测试的代码中，建议将测试部分单独写在一个文件，优势如下： 1）测试模块可以单独在命令行运行； 2）测试代码部分可以更容易的单独拿出来； 3）不会为了迎合被测试代码而随意修改测试代码； 4）测试代码修改少； 5）被测试代码容易被重构。 6）如果测试策略改变了，不需要去修改源码。

使用者会发现现存的一些旧的测试代码并不是TestCase的子类，但是仍需要执行。 基于此，unittest提供了FunctionTestCase类。TestCase的子类可以直接包含这些旧的测试类，并且同样可以实现用例的setUp()初始化和tearDown()销毁操作。

此时可以创建1个等效的测试用例，包含set-up和tear-down方法。

注意：FunctionTestCase可以很快的将普通测试方法转换成单元测试，但一般不建议。尽量花时间去构造TestCase的子类作为测试将会使以后重构更加容易。

有时候，已有的测试可能使用该doctest模块编写。如果是这样，请doctest提供一个DocTestSuite类，该类可以unittest.TestSuite根据现有doctest基于现有的测试自动构建实例。

3.1版本的新功能 unittest支持跳过单个测试方法甚至整个测试类别。此外，它支持将测试标记为“预期失败”，即已损坏且将失败的测试，但是这个失败不会在TestResult中记录。 跳过一个测试很简单，只需使用skip()或者附带一些条件判断的skip()。 代码如下;