Python - pytest

目录

10年积累的成都网站制作、成都网站设计、外贸营销网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有红旗免费网站建设让你可以放心的选择与我们合作。

pytest是Python的单元测试框架，同自带的unittest框架类似，但pytest框架使用起来更简洁，效率更高。

pytest特点

安装

测试

在测试之前要做的准备

我的演示脚本处于这样一个的目录中：

踩坑：你创建的pytest脚本名称中不允许含有 . ，比如 1.简单上手.py ，这样会报错。当然，可以这么写 1-简单上手.py

demo1.py ：

上例中，当我们在执行（就像Python解释器执行普通的Python脚本一样）测试用例的时候， pytest.main(["-s", "demo1.py"]) 中的传参需要是一个元组或者列表（我的pytest是5.2.2版本），之前的版本可能需要这么调用 pytest.main("-s demo1.py") ，传的参数是str的形式，至于你使用哪种，取决于报不报错：

遇到上述报错，就是参数需要一个列表或者元组的形式，而我们使用的是str形式。

上述代码正确的执行结果是这样的：

大致的信息就是告诉我们:

pytest.main(["-s", "demo1.py"])参数说明

除了上述的函数这种写法，也可以有用例类的写法：

用法跟unittest差不多，类名要以 Test 开头，并且其中的用例方法也要以 test 开头，然后执行也一样。

执行结果：

那么，你这个时候可能会问，我记得unittest中有setup和teardown的方法，难道pytest中没有嘛？你怎么提都不提？稳住，答案是有的。

接下来，我们来研究一下pytest中的setup和teardown的用法。

我们知道，在unittest中，setup和teardown可以在每个用例前后执行，也可以在所有的用例集执行前后执行。那么在pytest中，有以下几种情况：

来一一看看各自的用法。

模块级别setup_module/teardown_module

执行结果：

类级别的setup_class/teardown_class

执行结果：

类中方法级别的setup_method/teardown_method

执行结果：

函数级别的setup_function/teardown_function

执行结果：

小结

该脚本有多种运行方式，如果处于PyCharm环境，可以使用右键或者点击运行按钮运行，也就是在pytest中的主函数中运行：

也可以在命令行中运行：

这种方式，跟使用Python解释器执行Python脚本没有什么两样。也可以如下面这么执行：

当然，还有一种是使用配置文件运行，来看看怎么用。

在项目的根目录下，我们可以建立一个 pytest.ini 文件，在这个文件中，我们可以实现相关的配置：

那这个配置文件中的各项都是什么意思呢？

首先， pytest.ini 文件必须位于项目的根目录，而且也必须叫做 pytest.ini 。

其他的参数：

OK，来个示例。

首先，（详细目录参考开头的目录结构）在 scripts/test_case_01.py 中：

在 scripts/test_case_dir1/test_case02.py 中：

那么，在不同的目录或者文件中，共有5个用例将被执行，而结果则是两个失败三个成功。来执行验证一下，因为有了配置文件，我们在终端中（前提是在项目的根目录），直接输入 pytest 即可。

由执行结果可以发现， 2 failed, 3 passed ，跟我们的预期一致。

后续执行相关配置都来自配置文件，如果更改，会有相应说明，终端都是直接使用 pytest 执行。

我们知道在unittest中，跳过用例可以用 skip ，那么这同样是适用于pytest。

来看怎么使用：

跳过用例，我们使用 @pytest.mark.skipif(condition, reason) ：

然后将它装饰在需要被跳过用例的的函数上面。

效果如下：

上例执行结果相对详细，因为我们在配置文件中为 addopts 增加了 -v ，之前的示例结果中，没有加！

另外，此时，在输出的控制台中， 还无法打印出 reason 信息，如果需要打印，则可以在配置文件中的 addopts 参数的 -s 变为 -rs ：

如果我们事先知道测试函数会执行失败，但又不想直接跳过，而是希望显示的提示。

Pytest 使用 pytest.mark.xfail 实现预见错误功能：：

需要掌握的必传参数的是：

那么关于预期失败的几种情况需要了解一下：

结果如下：

pytest 使用 x 表示预见的失败（XFAIL）。

如果预见的是失败，但实际运行测试却成功通过，pytest 使用 X 进行标记（XPASS）。

而在预期失败的两种情况中，我们不希望出现预期失败，结果却执行成功了的情况出现，因为跟我们想的不一样嘛，我预期这条用例失败，那这条用例就应该执行失败才对，你虽然执行成功了，但跟我想的不一样，你照样是失败的！

所以，我们需要将预期失败，结果却执行成功了的用例标记为执行失败，可以在 pytest.ini 文件中，加入：

这样就就把上述的情况标记为执行失败了。

pytest身为强大的单元测试框架，那么同样支持DDT数据驱动测试的概念。也就是当对一个测试函数进行测试时，通常会给函数传递多组参数。比如测试账号登陆，我们需要模拟各种千奇百怪的账号密码。

当然，我们可以把这些参数写在测试函数内部进行遍历。不过虽然参数众多，但仍然是一个测试，当某组参数导致断言失败，测试也就终止了。

通过异常捕获，我们可以保证程所有参数完整执行，但要分析测试结果就需要做不少额外的工作。

在 pytest 中，我们有更好的解决方法，就是参数化测试，即每组参数都独立执行一次测试。使用的工具就是 pytest.mark.parametrize(argnames, argvalues) 。

使用就是以装饰器的形式使用。

只有一个参数的测试用例

来看（重要部分）结果：：

可以看到，列表内的每个手机号，都是一条测试用例。

多个参数的测试用例

（重要部分）结果：

可以看到，每一个手机号与每一个验证码都组合一起执行了，这样就执行了4次。那么如果有很多个组合的话，用例数将会更多。我们希望手机号与验证码一一对应组合，也就是只执行两次，怎么搞呢？

在多参数情况下，多个参数名是以 , 分割的字符串。参数值是列表嵌套的形式组成的。

固件（Fixture）是一些函数，pytest 会在执行测试函数之前（或之后）加载运行它们，也称测试夹具。

我们可以利用固件做任何事情，其中最常见的可能就是数据库的初始连接和最后关闭操作。

Pytest 使用 pytest.fixture() 定义固件，下面是最简单的固件，访问主页前必须先登录：

结果：

在之前的示例中，你可能会觉得，这跟之前的setup和teardown的功能也类似呀，但是，fixture相对于setup和teardown来说更灵活。pytest通过 scope 参数来控制固件的使用范围，也就是作用域。

比如之前的login固件，可以指定它的作用域：

很多时候需要在测试前进行预处理（如新建数据库连接），并在测试完成进行清理（关闭数据库连接）。

当有大量重复的这类操作，最佳实践是使用固件来自动化所有预处理和后处理。

Pytest 使用 yield 关键词将固件分为两部分， yield 之前的代码属于预处理，会在测试前执行； yield 之后的代码属于后处理，将在测试完成后执行。

以下测试模拟数据库查询，使用固件来模拟数据库的连接关闭：

结果：

可以看到在两个测试用例执行前后都有预处理和后处理。

pytest中还有非常多的插件供我们使用，我们来介绍几个常用的。

先来看一个重要的，那就是生成测试用例报告。

想要生成测试报告，首先要有下载，才能使用。

下载

如果下载失败，可以使用PyCharm下载，怎么用PyCharm下载这里无需多言了吧。

使用

在配置文件中，添加参数：

效果很不错吧！

没完，看我大招

Allure框架是一个灵活的轻量级多语言测试报告工具，它不仅以web的方式展示了简洁的测试结果，而且允许参与开发过程的每个人从日常执行的测试中最大限度的提取有用信息。

从开发人员（dev，developer）和质量保证人员（QA，Quality Assurance）的角度来看，Allure报告简化了常见缺陷的统计：失败的测试可以分为bug和被中断的测试，还可以配置日志、步骤、fixture、附件、计时、执行 历史 以及与TMS和BUG管理系统集成，所以，通过以上配置，所有负责的开发人员和测试人员可以尽可能的掌握测试信息。

从管理者的角度来看，Allure提供了一个清晰的“大图”，其中包括已覆盖的特性、缺陷聚集的位置、执行时间轴的外观以及许多其他方便的事情。allure的模块化和可扩展性保证了我们总是能够对某些东西进行微调。

少扯点，来看看怎么使用。

Python的pytest中allure下载

但由于这个 allure-pytest 插件生成的测试报告不是 html 类型的，我们还需要使用allure工具再“加工”一下。所以说，我们还需要下载这个allure工具。

allure工具下载

在现在allure工具之前，它依赖Java环境，我们还需要先配置Java环境。

注意，如果你的电脑已经有了Java环境，就无需重新配置了。

配置完了Java环境，我们再来下载allure工具，我这里直接给出了百度云盘链接，你也可以去其他链接中自行下载：

下载并解压好了allure工具包之后，还需要将allure包内的 bin 目录添加到系统的环境变量中。

完事后打开你的终端测试：

返回了版本号说明安装成功。

使用

一般使用allure要经历几个步骤：

来看配置 pytest.ini ：

就是 --alluredir ./report/result 参数。

在终端中输入 pytest 正常执行测试用例即可：

执行完毕后，在项目的根目下，会自动生成一个 report 目录，这个目录下有：

接下来需要使用allure工具来生成HTML报告。

此时我们在终端（如果是windows平台，就是cmd），路径是项目的根目录，执行下面的命令。

PS：我在pycharm中的terminal输入allure提示'allure' 不是内部或外部命令，也不是可运行的程序或批处理文件。但windows的终端没有问题。

命令的意思是，根据 reportresult 目录中的数据（这些数据是运行pytest后产生的）。在 report 目录下新建一个 allure_html 目录，而这个目录内有 index.html 才是最终的allure版本的HTML报告；如果你是重复执行的话，使用 --clean 清除之前的报告。

结果很漂亮：

allure open

默认的，allure报告需要HTTP服务器来打开，一般我们可以通过pycharm来完成，另外一种情况就是通过allure自带的open命令来完成。

allure的其他用法

当然，故事还是没有完！在使用allure生成报告的时候，在编写用例阶段，还可以有一些参数可以使用：

allure.title与allure.description

feature和story

由上图可以看到，不同的用例被分为不同的功能中。

allure.severity

allure.severity 用来标识测试用例或者测试类的级别，分为blocker，critical，normal，minor，trivial5个级别。

severity的默认级别是normal，所以上面的用例5可以不添加装饰器了。

allure.dynamic

在之前，用例的执行顺序是从上到下依次执行：

正如上例的执行顺序是 3 1 2 。

现在，来看看我们如何手动控制多个用例的执行顺序，这里也依赖一个插件。

下载

使用

手动控制用例执行顺序的方法是在给各用例添加一个装饰器：

那么， 现在的执行顺序是 2 1 3 ，按照order指定的排序执行的。

如果有人较劲传个0或者负数啥的，那么它们的排序关系应该是这样的：

失败重试意思是指定某个用例执行失败可以重新运行。

下载

使用

需要在 pytest.ini 文件中， 配置：

给 addopts 字段新增（其他原有保持不变） --reruns=3 字段，这样如果有用例执行失败，则再次执行，尝试3次。

来看示例：

结果：

我们也可以从用例报告中看出重试的结果：

上面演示了用例失败了，然后重新执行多少次都没有成功，这是一种情况。

接下来，来看另一种情况，那就是用例执行失败，重新执行次数内通过了，那么剩余的重新执行的次数将不再执行。

通过 random 模块帮助我们演示出在某次执行中出现失败的情况，而在重新执行的时候，会出现成功的情况，看结果：

可以看到，用例 02 重新执行了一次就成功了，剩余的两次执行就终止了。

一条一条用例的执行，肯定会很慢，来看如何并发的执行测试用例，当然这需要相应的插件。

下载

使用

在配置文件中添加：

就是这个 -n=auto ：

并发的配置可以写在配置文件中，然后其他正常的执行用例脚本即可。另外一种就是在终端中指定，先来看示例：

结果：

pytest-sugar 改变了 pytest 的默认外观，添加了一个进度条，并立即显示失败的测试。它不需要配置，只需 下载插件即可，用 pytest 运行测试，来享受更漂亮、更有用的输出。

下载

其他照旧执行用例即可。

pytest-cov 在 pytest 中增加了覆盖率支持，来显示哪些代码行已经测试过，哪些还没有。它还将包括项目的测试覆盖率。

下载

使用

在配置文件中：

也就是配置 --cov=./scripts ，这样，它就会统计所有 scripts 目录下所有符合规则的脚本的测试覆盖率。

执行的话，就照常执行就行。

结果：

更多插件参考：

有的时候，在 pytest.ini 中配置了 pytest-html 和 allure 插件之后，执行后报错：

出现了这个报错，检查你配置的解释器中是否存在 pytest-html 和 allure-pytest 这两个模块。如果是使用的pycharm ide，那么你除了检查settings中的解释器配置之外，还需要保证运行脚本的编辑器配置是否跟settings中配置一致。

用python单元测试怎么测一段代码

单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。

比如对函数abs()，我们可以编写出以下几个测试用例：

输入正数，比如1、1.2、0.99，期待返回值与输入相同；

输入负数，比如-1、-1.2、-0.99，期待返回值与输入相反；

输入0，期待返回0；

输入非数值类型，比如None、[]、{}，期待抛出TypeError。

把上面的测试用例放到一个测试模块里，就是一个完整的单元测试。

如果单元测试通过，说明我们测试的这个函数能够正常工作。如果单元测试不通过，要么函数有bug，要么测试条件输入不正确，总之，需要修复使单元测试能够通过。

单元测试通过后有什么意义呢？如果我们对abs()函数代码做了修改，只需要再跑一遍单元测试，如果通过，说明我们的修改不会对abs()函数原有的行为造成影响，如果测试不通过，说明我们的修改与原有行为不一致，要么修改代码，要么修改测试。

这种以测试为驱动的开发模式最大的好处就是确保一个程序模块的行为符合我们设计的测试用例。在将来修改的时候，可以极大程度地保证该模块行为仍然是正确的。

我们来编写一个Dict类，这个类的行为和dict一致，但是可以通过属性来访问，用起来就像下面这样：

d = Dict(a=1, b=2)

d['a']

1

d.a

1

mydict.py代码如下：

class Dict(dict):

def __init__(self, **kw):

super(Dict, self).__init__(**kw)

def __getattr__(self, key):

try:

return self[key]

except KeyError:

raise AttributeError(r"'Dict' object has no attribute '%s'" % key)

def __setattr__(self, key, value):

self[key] = value

为了编写单元测试，我们需要引入Python自带的unittest模块，编写mydict_test.py如下：

import unittest

from mydict import Dict

class TestDict(unittest.TestCase):

def test_init(self):

d = Dict(a=1, b='test')

self.assertEquals(d.a, 1)

self.assertEquals(d.b, 'test')

self.assertTrue(isinstance(d, dict))

def test_key(self):

d = Dict()

d['key'] = 'value'

self.assertEquals(d.key, 'value')

def test_attr(self):

d = Dict()

d.key = 'value'

self.assertTrue('key' in d)

self.assertEquals(d['key'], 'value')

def test_keyerror(self):

d = Dict()

with self.assertRaises(KeyError):

value = d['empty']

def test_attrerror(self):

d = Dict()

with self.assertRaises(AttributeError):

value = d.empty

编写单元测试时，我们需要编写一个测试类，从unittest.TestCase继承。

以test开头的方法就是测试方法，不以test开头的方法不被认为是测试方法，测试的时候不会被执行。

对每一类测试都需要编写一个test_xxx()方法。由于unittest.TestCase提供了很多内置的条件判断，我们只需要调用这些方法就可以断言输出是否是我们所期望的。最常用的断言就是assertEquals()：

self.assertEquals(abs(-1), 1) # 断言函数返回的结果与1相等

另一种重要的断言就是期待抛出指定类型的Error，比如通过d['empty']访问不存在的key时，断言会抛出KeyError：

with self.assertRaises(KeyError):

value = d['empty']

而通过d.empty访问不存在的key时，我们期待抛出AttributeError：

with self.assertRaises(AttributeError):

value = d.empty

运行单元测试

一旦编写好单元测试，我们就可以运行单元测试。最简单的运行方式是在mydict_test.py的最后加上两行代码：

if __name__ == '__main__':

unittest.main()

这样就可以把mydict_test.py当做正常的python脚本运行：

$ python mydict_test.py

另一种更常见的方法是在命令行通过参数-m unittest直接运行单元测试：

$ python -m unittest mydict_test

.....

----------------------------------------------------------------------

Ran 5 tests in 0.000s

OK

这是推荐的做法，因为这样可以一次批量运行很多单元测试，并且，有很多工具可以自动来运行这些单元测试。

setUp与tearDown

可以在单元测试中编写两个特殊的setUp()和tearDown()方法。这两个方法会分别在每调用一个测试方法的前后分别被执行。

setUp()和tearDown()方法有什么用呢？设想你的测试需要启动一个数据库，这时，就可以在setUp()方法中连接数据库，在tearDown()方法中关闭数据库，这样，不必在每个测试方法中重复相同的代码：

class TestDict(unittest.TestCase):

def setUp(self):

print 'setUp...'

def tearDown(self):

print 'tearDown...'

可以再次运行测试看看每个测试方法调用前后是否会打印出setUp...和tearDown...。

后端编程Python3-调试、测试和性能剖析(下)

单元测试（Unit Testing）

为程序编写测试——如果做的到位——有助于减少bug的出现，并可以提高我们对程序按预期目标运行的信心。通常，测试并不能保证正确性，因为对大多数程序而言， 可能的输入范围以及可能的计算范围是如此之大，只有其中最小的一部分能被实际地进 行测试。尽管如此，通过仔细地选择测试的方法和目标，可以提高代码的质量。

大量不同类型的测试都可以进行，比如可用性测试、功能测试以及整合测试等。这里, 我们只讲单元测试一对单独的函数、类与方法进行测试，确保其符合预期的行为。

TDD的一个关键点是，当我们想添加一个功能时——比如为类添加一个方法—— 我们首次为其编写一个测试用例。当然，测试将失败，因为我们还没有实际编写该方法。现在，我们编写该方法，一旦方法通过了测试，就可以返回所有测试，确保我们新添加的代码没有任何预期外的副作用。一旦所有测试运行完毕（包括我们为新功能编写的测试），就可以对我们的代码进行检查，并有理有据地相信程序行为符合我们的期望——当然，前提是我们的测试是适当的。

比如，我们编写了一个函数，该函数在特定的索引位置插入一个字符串，可以像下面这样开始我们的TDD：

def insert_at（string, position, insert）:

"""Returns a copy of string with insert inserted at the position

string = "ABCDE"

result =[]

for i in range(-2, len(string) + 2):

... result.append(insert_at(string, i,“-”))

result[:5]

['ABC-DE', 'ABCD-E', '-ABCDE','A-BCDE', 'AB-CDE']

result[5:]

['ABC-DE', 'ABCD-E', 'ABCDE-', 'ABCDE-']

"""

return string

对不返回任何参数的函数或方法（通常返回None）,我们通常赋予其由pass构成的一个suite,对那些返回值被试用的，我们或者返回一个常数（比如0）,或者某个不变的参数——这也是我们这里所做的。（在更复杂的情况下，返回fake对象可能更有用一一对这样的类，提供mock对象的第三方模块是可用的。）

运行doctest时会失败，并列出每个预期内的字符串（'ABCD-EF'、'ABCDE-F' 等），及其实际获取的字符串（所有的都是'ABCD-EF'）。一旦确定doctest是充分的和正确的，就可以编写该函数的主体部分，在本例中只是简单的return string[:position] + insert+string[position:]。（如果我们编写的是 return string[:position] + insert,之后复制 string [:position]并将其粘贴在末尾以便减少一些输入操作，那么doctest会立即提示错误。）

Python的标准库提供了两个单元测试模块，一个是doctest,这里和前面都简单地提到过，另一个是unittest。此外，还有一些可用于Python的第三方测试工具。其中最著名的两个是nose (code.google.com/p/python-nose)与py.test (codespeak.net/py/dist/test/test.html), nose 致力于提供比标准的unittest 模块更广泛的功能，同时保持与该模块的兼容性，py.test则采用了与unittest有些不同的方法，试图尽可能消除样板测试代码。这两个第三方模块都支持测试发现，因此没必要写一个总体的测试程序——因为模块将自己搜索测试程序。这使得测试整个代码树或某一部分 (比如那些已经起作用的模块)变得很容易。那些对测试严重关切的人，在决定使用哪个测试工具之前，对这两个(以及任何其他有吸引力的)第三方模块进行研究都是值 得的。

创建doctest是直截了当的：我们在模块中编写测试、函数、类与方法的docstrings。 对于模块，我们简单地在末尾添加了 3行：

if __name__ =="__main__":

import doctest

doctest.testmod()

在程序内部使用doctest也是可能的。比如，blocks.py程序(其模块在后面)有自己函数的doctest，但以如下代码结尾：

if __name__== "__main__":

main()

这里简单地调用了程序的main()函数，并且没有执行程序的doctest。要实验程序的 doctest,有两种方法。一种是导入doctest模块，之后运行程序---比如，在控制台中输 入 python3 -m doctest blocks.py (在 Wndows 平台上，使用类似于 C:Python3 lpython.exe 这样的形式替代python3)。如果所有测试运行良好，就没有输出，因此，我们可能宁愿执行python3-m doctest blocks.py-v,因为这会列出每个执行的doctest,并在最后给出结果摘要。

另一种执行doctest的方法是使用unittest模块创建单独的测试程序。在概念上， unittest模块是根据Java的JUnit单元测试库进行建模的，并用于创建包含测试用例的测试套件。unittest模块可以基于doctests创建测试用例，而不需要知道程序或模块包含的任何事物——只要知道其包含doctest即可。因此，为给blocks.py程序制作一个测试套件，我们可以创建如下的简单程序(将其称为test_blocks.py)：

import doctest

import unittest

import blocks

suite = unittest.TestSuite()

suite.addTest(doctest.DocTestSuite(blocks))

runner = unittest.TextTestRunner()

print(runner.run(suite))

注意，如果釆用这种方法，程序的名称上会有一个隐含的约束：程序名必须是有效的模块名。因此，名为convert-incidents.py的程序的测试不能写成这样。因为import convert-incidents不是有效的，在Python标识符中，连接符是无效的（避开这一约束是可能的，但最简单的解决方案是使用总是有效模块名的程序文件名，比如，使用下划线替换连接符）。这里展示的结构（创建一个测试套件，添加一个或多个测试用例或测试套件，运行总体的测试套件，输出结果）是典型的机遇unittest的测试。运行时，这一特定实例产生如下结果：

...

.............................................................................................................

Ran 3 tests in 0.244s

OK

每次执行一个测试用例时，都会输出一个句点（因此上面的输出最前面有3个句点），之后是一行连接符，再之后是测试摘要（如果有任何一个测试失败，就会有更多的输出信息）。

如果我们尝试将测试分离开（典型情况下是要测试的每个程序和模块都有一个测试用例），就不要再使用doctests,而是直接使用unittest模块的功能——尤其是我们习惯于使用JUnit方法进行测试时ounittest模块会将测试分离于代码——对大型项目（测试编写人员与开发人员可能不一致）而言，这种方法特别有用。此外，unittest单元测试编写为独立的Python模块，因此，不会像在docstring内部编写测试用例时受到兼容性和明智性的限制。

unittest模块定义了 4个关键概念。测试夹具是一个用于描述创建测试（以及用完之后将其清理）所必需的代码的术语，典型实例是创建测试所用的一个输入文件，最后删除输入文件与结果输出文件。测试套件是一组测试用例的组合。测试用例是测试的基本单元—我们很快就会看到实例。测试运行者是执行一个或多个测试套件的对象。

典型情况下，测试套件是通过创建unittest.TestCase的子类实现的，其中每个名称 以“test”开头的方法都是一个测试用例。如果我们需要完成任何创建操作，就可以在一个名为setUp()的方法中实现；类似地，对任何清理操作，也可以实现一个名为 tearDown()的方法。在测试内部，有大量可供我们使用的unittest.TestCase方法，包括 assertTrue()、assertEqual()、assertAlmostEqual()（对于测试浮点数很有用）、assertRaises() 以及更多，还包括很多对应的逆方法，比如assertFalse()、assertNotEqual()、failIfEqual()、 failUnlessEqual ()等。

unittest模块进行了很好的归档，并且提供了大量功能，但在这里我们只是通过一 个非常简单的测试套件来感受一下该模块的使用。这里将要使用的实例,该练习要求创建一个Atomic模块，该模块可以用作一 个上下文管理器，以确保或者所有改变都应用于某个列表、集合或字典，或者所有改变都不应用。作为解决方案提供的Atomic.py模块使用30行代码来实现Atomic类， 并提供了 100行左右的模块doctest。这里，我们将创建test_Atomic.py模块，并使用 unittest测试替换doctest,以便可以删除doctest。

在编写测试模块之前，我们需要思考都需要哪些测试。我们需要测试3种不同的数据类型：列表、集合与字典。对于列表，需要测试的是插入项、删除项或修改项的值。对于集合，我们必须测试向其中添加或删除一个项。对于字典，我们必须测试的是插入一个项、修改一个项的值、删除一个项。此外，还必须要测试的是在失败的情况下，不会有任何改变实际生效。

结构上看，测试不同数据类型实质上是一样的，因此，我们将只为测试列表编写测试用例，而将其他的留作练习。test_Atomic.py模块必须导入unittest模块与要进行测试的Atomic模块。

创建unittest文件时，我们通常创建的是模块而非程序。在每个模块内部，我们定义一个或多个unittest.TestCase子类。比如，test_Atomic.py模块中仅一个单独的 unittest-TestCase子类，也就是TestAtomic (稍后将对其进行讲解)，并以如下两行结束:

if name == "__main__":

unittest.main()

这两行使得该模块可以单独运行。当然，该模块也可以被导入并从其他测试程序中运行——如果这只是多个测试套件中的一个，这一点是有意义的。

如果想要从其他测试程序中运行test_Atomic.py模块，那么可以编写一个与此类似的程序。我们习惯于使用unittest模块执行doctests,比如：

import unittest

import test_Atomic

suite = unittest.TestLoader().loadTestsFromTestCase(test_Atomic.TestAtomic)

runner = unittest.TextTestRunner()

pnnt(runner.run(suite))

这里，我们已经创建了一个单独的套件，这是通过让unittest模块读取test_Atomic 模块实现的，并且使用其每一个test*()方法(本实例中是test_list_success()、test_list_fail()，稍后很快就会看到)作为测试用例。

我们现在将查看TestAtomic类的实现。对通常的子类(不包括unittest.TestCase 子类)，不怎么常见的是，没有必要实现初始化程序。在这一案例中，我们将需要建立 一个方法，但不需要清理方法，并且我们将实现两个测试用例。

def setUp(self)：

self.original_list = list(range(10))

我们已经使用了 unittest.TestCase.setUp()方法来创建单独的测试数据片段。

def test_list_succeed(self):

items = self.original_list[:]

with Atomic.Atomic(items) as atomic:

atomic.append(1999)

atomic.insert(2, -915)

del atomic[5]

atomic[4]= -782

atomic.insert(0, -9)

self.assertEqual(items,

[-9, 0, 1, -915, 2, -782, 5, 6, 7, 8, 9, 1999])

def test_list_fail(self):

items = self.original_list[:]

with self.assertRaises(AttributeError):

with Atomic.Atomic(items) as atomic:

atomic.append(1999)

atomic.insert(2, -915)

del atomic[5]

atomic[4] = -782

atomic.poop() # Typo

self.assertListEqual(items, self.original_list)

这里，我们直接在测试方法中编写了测试代码，而不需要一个内部函数，也不再使用unittest.TestCase.assertRaised()作为上下文管理器(期望代码产生AttributeError)。 最后我们也使用了 Python 3.1 的 unittest.TestCase.assertListEqual()方法。

正如我们已经看到的，Python的测试模块易于使用，并且极为有用，在我们使用 TDD的情况下更是如此。它们还有比这里展示的要多得多的大量功能与特征——比如，跳过测试的能力，这有助于理解平台差别——并且这些都有很好的文档支持。缺失的一个功能——但nose与py.test提供了——是测试发现，尽管这一特征被期望在后续的Python版本(或许与Python 3.2—起)中出现。

性能剖析（Profiling）

如果程序运行很慢，或者消耗了比预期内要多得多的内存，那么问题通常是选择的算法或数据结构不合适，或者是以低效的方式进行实现。不管问题的原因是什么， 最好的方法都是准确地找到问题发生的地方,而不只是检査代码并试图对其进行优化。 随机优化会导致引入bug,或者对程序中本来对程序整体性能并没有实际影响的部分进行提速，而这并非解释器耗费大部分时间的地方。

在深入讨论profiling之前，注意一些易于学习和使用的Python程序设计习惯是有意义的，并且对提高程序性能不无裨益。这些技术都不是特定于某个Python版本的， 而是合理的Python程序设计风格。第一，在需要只读序列时，最好使用元组而非列表； 第二，使用生成器，而不是创建大的元组和列表并在其上进行迭代处理；第三，尽量使用Python内置的数据结构 dicts、lists、tuples 而不实现自己的自定义结构，因为内置的数据结构都是经过了高度优化的；第四，从小字符串中产生大字符串时， 不要对小字符串进行连接，而是在列表中累积，最后将字符串列表结合成为一个单独的字符串；第五，也是最后一点，如果某个对象(包括函数或方法)需要多次使用属性进行访问(比如访问模块中的某个函数)，或从某个数据结构中进行访问，那么较好的做法是创建并使用一个局部变量来访问该对象，以便提供更快的访问速度。

Python标准库提供了两个特别有用的模块，可以辅助调査代码的性能问题。一个是timeit模块——该模块可用于对一小段Python代码进行计时，并可用于诸如对两个或多个特定函数或方法的性能进行比较等场合。另一个是cProfile模块，可用于profile 程序的性能——该模块对调用计数与次数进行了详细分解，以便发现性能瓶颈所在。

为了解timeit模块，我们将查看一些小实例。假定有3个函数function_a()、 function_b()、function_c(), 3个函数执行同样的计算，但分别使用不同的算法。如果将这些函数放于同一个模块中(或分别导入)，就可以使用timeit模块对其进行运行和比较。下面给出的是模块最后使用的代码：

if __name__ == "__main__":

repeats = 1000

for function in ("function_a", "function_b", "function_c"):

t = timeit.Timer("{0}(X, Y)".format(function),"from __main__ import {0}, X, Y".format(function))

sec = t.timeit(repeats) / repeats

print("{function}() {sec:.6f} sec".format(**locals()))

赋予timeit.Timer()构造子的第一个参数是我们想要执行并计时的代码，其形式是字符串。这里，该字符串是“function_a(X,Y)”；第二个参数是可选的，还是一个待执行的字符串，这一次是在待计时的代码之前，以便提供一些建立工作。这里，我们从 __main__ (即this)模块导入了待测试的函数，还有两个作为输入数据传入的变量(X 与Y),这两个变量在该模块中是作为全局变量提供的。我们也可以很轻易地像从其他模块中导入数据一样来进行导入操作。

调用timeit.Timer对象的timeit()方法时，首先将执行构造子的第二个参数(如果有)， 之后执行构造子的第一个参数并对其执行时间进行计时。timeit.Timer.timeit()方法的返回值是以秒计数的时间，类型是float。默认情况下，timeit()方法重复100万次，并返回所 有这些执行的总秒数，但在这一特定案例中，只需要1000次反复就可以给出有用的结果, 因此对重复计数次数进行了显式指定。在对每个函数进行计时后，使用重复次数对总数进行除法操作，就得到了平均执行时间，并在控制台中打印出函数名与执行时间。

function_a() 0.001618 sec

function_b() 0.012786 sec

function_c() 0.003248 sec

在这一实例中，function_a()显然是最快的——至少对于这里使用的输入数据而言。 在有些情况下一一比如输入数据不同会对性能产生巨大影响——可能需要使用多组输入数据对每个函数进行测试，以便覆盖有代表性的测试用例，并对总执行时间或平均执行时间进行比较。

有时监控自己的代码进行计时并不是很方便，因此timeit模块提供了一种在命令行中对代码执行时间进行计时的途径。比如，要对MyModule.py模块中的函数function_a()进行计时，可以在控制台中输入如下命令：python3 -m timeit -n 1000 -s "from MyModule import function_a, X, Y" "function_a(X, Y)"(与通常所做的一样，对 Windows 环境，我们必须使用类似于C:Python3lpython.exe这样的内容来替换python3)。-m选项用于Python 解释器，使其可以加载指定的模块(这里是timeit),其他选项则由timeit模块进行处理。 -n选项指定了循环计数次数，-s选项指定了要建立，最后一个参数是要执行和计时的代码。命令完成后，会向控制台中打印运行结果，比如：

1000 loops, best of 3: 1.41 msec per loop

之后我们可以轻易地对其他两个函数进行计时，以便对其进行整体的比较。

cProfile模块(或者profile模块，这里统称为cProfile模块)也可以用于比较函数 与方法的性能。与只是提供原始计时的timeit模块不同的是，cProfile模块精确地展示 了有什么被调用以及每个调用耗费了多少时间。下面是用于比较与前面一样的3个函数的代码：

if __name__ == "__main__":

for function in ("function_a", "function_b", "function_c"):

cProfile.run("for i in ranged 1000): {0}(X, Y)".format(function))

我们必须将重复的次数放置在要传递给cProfile.run()函数的代码内部，但不需要做任何创建，因为模块函数会使用内省来寻找需要使用的函数与变量。这里没有使用显式的print()语句，因为默认情况下，cProfile.run()函数会在控制台中打印其输出。下面给出的是所有函数的相关结果(有些无关行被省略，格式也进行了稍许调整，以便与页面适应)：

1003 function calls in 1.661 CPU seconds

ncalls tottime percall cumtime percall filename:lineno(function)

1 0.003 0.003 1.661 1.661 :1 ( )

1000 1.658 0.002 1.658 0.002 MyModule.py:21 (function_a)

1 0.000 0.000 1.661 1.661 {built-in method exec}

5132003 function calls in 22.700 CPU seconds

ncalls tottime percall cumtime percall filename:lineno(function)

1 0.487 0.487 22.700 22.700 : 1 ( )

1000 0.011 0.000 22.213 0.022 MyModule.py:28(function_b)

5128000 7.048 0.000 7.048 0.000 MyModule.py:29( )

1000 0.00 50.000 0.005 0.000 {built-in method bisectjeft}

1 0.000 0.000 22.700 22.700 {built-in method exec}

1000 0.001 0.000 0.001 0.000 {built-in method len}

1000 15.149 0.015 22.196 0.022 {built-in method sorted}

5129003 function calls in 12.987 CPU seconds

ncalls tottime percall cumtime percall filename:lineno(function)

1 0.205 0.205 12.987 12.987 :l ( )

1000 6.472 0.006 12.782 0.013 MyModule.py:36(function_c)

5128000 6.311 0.000 6.311 0.000 MyModule.py:37( )

1 0.000 0.000 12.987 12.987 {built-in method exec}

ncalls ("调用的次数")列列出了对指定函数(在filename:lineno(function)中列出) 的调用次数。回想一下我们重复了 1000次调用，因此必须将这个次数记住。tottime (“总的时间”)列列出了某个函数中耗费的总时间，但是排除了函数调用的其他函数内部花费的时间。第一个percall列列出了对函数的每次调用的平均时间(tottime // ncalls)。 cumtime ("累积时间")列出了在函数中耗费的时间，并且包含了函数调用的其他函数内部花费的时间。第二个percall列列出了对函数的每次调用的平均时间，包括其调用的函数耗费的时间。

这种输出信息要比timeit模块的原始计时信息富有启发意义的多。我们立即可以发现，function_b()与function_c()使用了被调用5000次以上的生成器，使得它们的速度至少要比function_a()慢10倍以上。并且，function_b()调用了更多通常意义上的函数，包括调用内置的sorted()函数，这使得其几乎比function_c()还要慢两倍。当然,timeit() 模块提供了足够的信息来查看计时上存在的这些差别，但cProfile模块允许我们了解为什么会存在这些差别。正如timeit模块允许对代码进行计时而又不需要对其监控一样，cProfile模块也可以做到这一点。然而，从命令行使用cProfile模块时，我们不能精确地指定要执行的 是什么——而只是执行给定的程序或模块，并报告所有这些的计时结果。需要使用的 命令行是python3 -m cProfile programOrModule.py,产生的输出信息与前面看到的一 样，下面给出的是输出信息样例，格式上进行了一些调整，并忽略了大多数行：

10272458 function calls (10272457 primitive calls) in 37.718 CPU secs

ncalls tottime percall cumtime percall filename:lineno(function)

10.000 0.000 37.718 37.718 :1 ( )

10.719 0.719 37.717 37.717 :12( )

1000 1.569 0.002 1.569 0.002 :20(function_a)

1000 0.011 0.000 22.560 0.023 :27(function_b)

5128000 7.078 0.000 7.078 0.000 :28( )

1000 6.510 0.007 12.825 0.013 :35(function_c)

5128000 6.316 0.000 6.316 0.000 :36( )

在cProfile术语学中，原始调用指的就是非递归的函数调用。

以这种方式使用cProfile模块对于识别值得进一步研究的区域是有用的。比如，这里 我们可以清晰地看到function_b()需要耗费更长的时间，但是我们怎样获取进一步的详细资料？我们可以使用cProfile.run("function_b()")来替换对function_b()的调用。或者可以保存完全的profile数据并使用pstats模块对其进行分析。要保存profile,就必须对命令行进行稍许修改:python3 -m cProfile -o profileDataFile programOrModule.py。 之后可以对 profile 数据进行分析，比如启动IDLE,导入pstats模块，赋予其已保存的profileDataFile,或者也可以在控制台中交互式地使用pstats。

下面给出的是一个非常短的控制台会话实例，为使其适合页面展示，进行了适当调整，我们自己的输入则以粗体展示：

$ python3 -m cProfile -o profile.dat MyModule.py

$ python3 -m pstats

Welcome to the profile statistics browser.

% read profile.dat

profile.dat% callers function_b

Random listing order was used

List reduced from 44 to 1 due to restriction

Function was called by...

ncalls tottime cumtime

:27(function_b) - 1000 0.011 22.251 :12( )

profile.dat% callees function_b

Random listing order was used

List reduced from 44 to 1 due to restriction

Function called...

ncalls tottime cumtime

:27(function_b)-

1000 0.005 0.005 built-in method bisectJeft

1000 0.001 0.001 built-in method len

1000 1 5.297 22.234 built-in method sorted

profile.dat% quit

输入help可以获取命令列表，help后面跟随命令名可以获取该命令的更多信息。比如, help stats将列出可以赋予stats命令的参数。还有其他一些可用的工具，可以提供profile数据的图形化展示形式，比如 RunSnakeRun (), 该工具需要依赖于wxPython GUI库。

使用timeit与cProfile模块，我们可以识别出我们自己代码中哪些区域会耗费超过预期的时间；使用cProfile模块，还可以准确算岀时间消耗在哪里。

以上内容部分摘自视频课程 05后端编程Python-19调试、测试和性能调优(下) ，更多实操示例请参照视频讲解。跟着张员外讲编程，学习更轻松，不花钱还能学习真本领。

python单元测试--mock

使用mock，可以将某个函数所依赖的对象或者变量mock掉，从而降低测试条件的负责度。如下所示：

上述是mock对象的简单使用方法，通过实例化一个Mock对象从而模拟掉原始函数的返回值，高级一些的用法就是通过mock.patch装饰器，装饰在类或者函数上进行模拟测试，如下在test.py文件中有两个类：

测试用例设计如下：

以上测试用例说明，通过patch装饰器模拟了 test.ProductionClass1 这个类，在 test_01 中使用 mock_class 模拟 test.ProductionClass1 。首先通过 mock_class.return_value 获取类实例（如果模拟的是函数，则不需要这一步），然后通过 obj1.pro1_method.return_value 设置方法的返回值，并进行测试。测试结果说明无论是通过 mock_class 还是 test.ProductionClass1 还是 obj1 执行方法，获取到的结果都是设置的值，并且在另一个类中调用模拟类的方法，也能成功获取到设置的 return_value 。

网站名称：python单元测试函数的简单介绍
本文路径：http://myzitong.com/article/dojgcdo.html