unittest-单元测试框架
源代码： Lib / unittest / __ init__.p
（如果您已经熟悉测试的基本概念则可能要跳到assert方法的列表。）
该unittest单元测试框架最初是由JUnit的启发，也有类似的味道在其他语言主要单元测试框架。它支持测试自动化，共享测试的设置和关闭代码，将测试聚合到集合中以及测试与报告框架的独立性。
为此，unittest以面向对象的方式支持一些重要的概念：
测试治具
甲测试夹具表示执行一个或多个测试所需要的制剂，以及任何相关的清除动作。例如，这可能涉及创建临时或代理数据库，目录或启动服务器进程。
测试用例
甲测试用例是测试的各个单元。它检查对一组特定输入的特定响应。 unittest提供了一个基类， TestCase可用于创建新的测试用例。
测试套件
一个测试套件是测试案例，测试套件，或两者的集合。它用于汇总应一起执行的测试。
测试选手
甲测试运行是编排的测试的执行，并提供结果给用户的部件。跑步者可以使用图形界面，文本界面，或返回特殊值以指示执行测试的结果。
也可以看看
模块 doctest
另一个测试支持模块具有非常不同的风格。
简单的Smalltalk测试：使用模式
肯特·贝克（Kent Beck）关于使用共享模式的测试框架的原始论文unittest。
pytest
第三方单元测试框架，用于编写测试的语法较轻。例如，。assert func(10) == 42
Python测试工具分类法
Python测试工具的广泛列表，包括功能测试框架和模拟对象库。
在Python邮件列表中进行测试
一个特殊兴趣小组，讨论Python中的测试和测试工具。
Tools/unittestgui/unittestgui.pyPython源代码分发中的脚本是用于测试发现和执行的GUI工具。这主要是为了使单元测试新手易于使用。对于生产环境，建议使用连续集成系统（例如Buildbot，Jenkins 或Travis-CI或AppVeyor）来驱动测试 。
基本例子
该unittest模块提供了丰富的工具来构建和运行测试。本节说明，仅需使用一小部分工具即可满足大多数用户的需求。
这是测试三个字符串方法的简短脚本：
import unittest
class TestStringMethods(unittest.TestCase):
def test_upper(self):
self.assertEqual('foo'.upper(), 'FOO')
def test_isupper(self):
self.assertTrue('FOO'.isupper())
self.assertFalse('Foo'.isupper())
def test_split(self):
s = 'hello world'
self.assertEqual(s.split(), ['hello', 'world'])
# check that s.split fails when the separator is not a string
with self.assertRaises(TypeError):
s.split(2)
if name == ‘main’:
unittest.main()
测试用例是通过子类创建的unittest.TestCase。这三个单独的测试使用名称以字母开头的方法定义 test。该命名约定将告知测试运行者哪些方法表示测试。
每个测试的症结在于要求assertEqual()检查预期结果。assertTrue()或assertFalse() 验证条件；或assertRaises()验证是否引发了特定的异常。使用这些方法代替 assert语句，因此测试运行程序可以累积所有测试结果并生成报告。
该setUp()和tearDown()方法允许你定义将在每次测试方法之后执行的指令。在组织测试代码部分中将更详细地介绍它们。
最后一块显示了运行测试的简单方法。unittest.main() 提供测试脚本的命令行界面。从命令行运行时，上面的脚本产生的输出看起来像这样：
…
Ran 3 tests in 0.000s
OK
将-v选项传递给测试脚本将指示unittest.main() 启用更高级别的详细程度，并产生以下输出：
test_isupper (main.TestStringMethods) … ok
test_split (main.TestStringMethods) … ok
test_upper (main.TestStringMethods) … ok
Ran 3 tests in 0.001s
OK
以上示例显示了最常用的unittest功能，足以满足许多日常测试需求。本文档的其余部分从第一个原理探讨了完整的功能集。
命令行界面
可以从命令行使用unittest模块从模块，类甚至单个测试方法运行测试：
python -m unittest test_module1 test_module2
python -m unittest test_module.TestClass
python -m unittest test_module.TestClass.test_method
您可以传入一个列表，其中包含模块名称以及完全限定的类或方法名称的任意组合。
测试模块也可以通过文件路径指定：
python -m unittest tests/test_something.py
这使您可以使用Shell文件名补全来指定测试模块。指定的文件必须仍然可以作为模块导入。通过删除“ .py”并将路径分隔符转换为“。”，可将该路径转换为模块名称。如果要执行不可作为模块导入的测试文件，则应直接执行该文件。
您可以通过传递-v标志来更详细（更详细）地运行测试：
python -m unittest -v test_module
不带参数执行时，将启动“测试发现”：
python -m unittest
有关所有命令行选项的列表：
python -m unittest -h
在3.2版中进行了更改：在早期版本中，只能运行单独的测试方法，而不能运行模块或类。
命令行选项
unittest支持以下命令行选项：
-b, --buffer
在测试运行期间，将缓冲标准输出和标准错误流。通过测试期间的输出将被丢弃。在测试失败或错误时，通常会回显输出，并将其添加到失败消息中。
-c, --catch
Control-C在测试运行期间，等待当前测试结束，然后报告到目前为止的所有结果。一秒钟Control-C引发正常 KeyboardInterrupt异常。
有关提供此功能的功能，请参见信号处理。
-f, --failfast
在第一个错误或失败时停止测试运行。
-k
仅运行与模式或子字符串匹配的测试方法和类。此选项可以多次使用，在这种情况下，将包括与给定模式匹配的所有测试用例。
包含通配符（*）的模式使用fnmatch.fnmatchcase()；与测试名称匹配；否则，使用简单的区分大小写的子字符串匹配。
模式与测试加载程序导入的完全合格的测试方法名称匹配。
例如，相匹配， 而不是。-k foofoo_tests.SomeTest.test_somethingbar_tests.SomeTest.test_foobar_tests.FooTest.test_something
–locals
在回溯中显示局部变量。
新的3.2版本：命令行选项-b，-c并-f添加。
3.5版的新功能：命令行选项–locals。
3.7版的新功能：命令行选项-k。
命令行还可以用于测试发现，运行项目中的所有测试或仅运行子集。
测试发现
3.2版中的新功能。
Unittest支持简单的测试发现。为了与测试发现兼容，所有测试文件必须是可从项目顶层目录导入的模块或 包（包括名称空间包）（这意味着它们的文件名必须是有效的标识符）。
测试发现在中实现TestLoader.discover()，但也可以从命令行使用。基本的命令行用法是：
cd project_directory
python -m unittest discover
笔记
作为快捷方式，等效于 。如果要传递参数以测试发现，则必须显式使用子命令。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，作为起始目录。然后，将提供您提供的软件包名称，并将其在文件系统上的位置用作开始目录。
警告
测试发现通过导入来加载测试。一旦测试发现从开始目录中找到了所有测试文件，您就可以指定将路径转换为要导入的程序包名称。例如，foo/bar/baz.py将导入为foo.bar.baz。
如果您在全球范围内安装了某个软件包，并尝试在该软件包的其他副本上进行测试发现，则可能会从错误的位置进行导入。如果发生这种情况，测试发现将警告您并退出。
如果您以包名而不是目录路径的形式提供开始目录，那么Discover会假设从其导入的任何位置都是您想要的位置，因此不会收到警告。
测试模块和软件包可以通过load_tests协议来自定义测试的加载和发现。
在版本3.4中进行了更改：测试发现支持 起始目录的名称空间包。请注意，您也需要顶层目录。（例如）。python -m unittest discover -s root/namespace -t root
组织测试代码
单元测试的基本组成部分是测试用例—必须设置单个场景并检查其正确性。在中unittest，测试用例由unittest.TestCase实例表示。要制作自己的测试用例，必须编写TestCase或的子类 FunctionTestCase。
TestCase实例的测试代码应完全独立，以使它可以隔离运行，也可以与任意数量的其他测试用例任意组合运行。
最简单的TestCase子类将简单地实现一个测试方法（即名称以开头的方法test），以执行特定的测试代码：
import unittest
class DefaultWidgetSizeTestCase(unittest.TestCase):
def test_default_widget_size(self):
widget = Widget(‘The widget’)
self.assertEqual(widget.size(), (50, 50))
请注意，为了测试某些内容，我们使用基类assert*() 提供的方法之一TestCase。如果测试失败，则会引发异常，并显示一条解释性消息，并将unittest 测试用例标识为失败。其他任何异常都将被视为错误。
测试可能很多，并且它们的设置可能是重复的。幸运的是，我们可以通过实现称为的方法来分解设置代码，setUp()测试框架将针对我们运行的每个测试自动调用该方法 ：
import unittest
class WidgetTestCase(unittest.TestCase):
def setUp(self):
self.widget = Widget(‘The widget’)
def test_default_widget_size(self):
self.assertEqual(self.widget.size(), (50,50),
'incorrect default size')
def test_widget_resize(self):
self.widget.resize(100,150)
self.assertEqual(self.widget.size(), (100,150),
'wrong size after resize')
笔记
通过根据字符串的内置顺序对测试方法名称进行排序，可以确定各种测试的运行顺序。
如果在setUp()测试运行时该方法引发异常，则框架将认为该测试已发生错误，并且该测试方法将不会执行。
同样，我们可以提供一种tearDown()在测试方法运行后进行整理的方法：
import unittest
class WidgetTestCase(unittest.TestCase):
def setUp(self):
self.widget = Widget(‘The widget’)
def tearDown(self):
self.widget.dispose()
如果setUp()成功，tearDown()将运行测试方法是否成功。
这种用于测试代码的工作环境称为 测试夹具。创建一个新的TestCase实例作为用于执行每种单独的测试方法的唯一测试夹具。因此 setUp()，tearDown()和__init__() 将在每个测试中被调用一次。
建议您使用TestCase实现将测试根据其测试的功能分组在一起。 unittest为此提供了一种机制：测试套件，由unittest的 TestSuite类表示。在大多数情况下，调用unittest.main()会做正确的事，并为您收集所有模块的测试用例并执行它们。
但是，如果您想自定义测试套件的构建，则可以自己进行：
def suite():
suite = unittest.TestSuite()
suite.addTest(WidgetTestCase(‘test_default_widget_size’))
suite.addTest(WidgetTestCase(‘test_widget_resize’))
return suite
if name == ‘main’:
runner = unittest.TextTestRunner()
runner.run(suite())
您可以将测试用例和测试套件的定义与它们要测试的代码放在相同的模块中（例如widget.py），但是将测试代码放在单独的模块中有许多优点，例如 test_widget.py：
- • 可以从命令行独立运行测试模块。
- • 测试代码可以更容易地与出厂代码分开。
- • 在没有充分理由的情况下，很少有更改测试代码以使其适合测试代码的诱惑。
- • 测试代码的修改频率应比其测试的频率低得多。
- • 经过测试的代码可以更容易地重构。
- • 无论如何，用C编写的模块的测试都必须在单独的模块中，所以为什么不一致？
- • 如果测试策略发生变化，则无需更改源代码。
重复使用旧的测试代码
一些用户会发现，他们已经拥有想要从中运行的现有测试代码unittest，而没有将每个旧的测试函数都转换为 TestCase子类。
因此，unittest提供了一个FunctionTestCase类。的这个子类TestCase可用于包装现有的测试功能。还可以提供设置和拆卸功能。
给定以下测试功能：
def testSomething():
something = makeSomething()
assert something.name is not None…
可以使用可选的设置和拆卸方法如下创建等效的测试用例实例：
testcase = unittest.FunctionTestCase(testSomething,
setUp=makeSomethingDB,
tearDown=deleteSomethingDB)
笔记
即使FunctionTestCase可以用来将现有的测试库快速转换为unittest基于系统的系统，也不建议使用此方法。花时间设置适当的TestCase 子类将使将来的测试重构变得更加轻松。
在某些情况下，现有测试可能已使用该doctest 模块编写。如果是这样，请doctest提供一个DocTestSuite类，该类可以unittest.TestSuite根据现有doctest基于现有的测试自动构建实例 。
跳过测试和预期的失败
3.1版中的新功能。
Unittest支持跳过单个测试方法甚至整个测试类别。此外，它支持将测试标记为“预期失败”，即已损坏且将失败的测试，但不应将其视为上的失败 TestResult。
跳过测试仅是使用装饰器 或其条件变量之一，在 或测试方法中调用或直接引发的问题。skip() TestCase.skipTest()setUp()SkipTest
基本跳过如下所示：
class MyTestCase(unittest.TestCase):
@unittest.skip("demonstrating skipping")
def test_nothing(self):
self.fail("shouldn't happen")
@unittest.skipIf(mylib.__version__ < (1, 3),
"not supported in this library version")
def test_format(self):
# Tests that work for only a certain version of the library.
pass
@unittest.skipUnless(sys.platform.startswith("win"), "requires Windows")
def test_windows_support(self):
# windows specific testing code
pass
def test_maybe_skipped(self):
if not external_resource_available():
self.skipTest("external resource not available")
# test code that depends on the external resource
pass
这是在详细模式下运行上述示例的输出：
test_format (main.MyTestCase) … skipped ‘not supported in this library version’
test_nothing (main.MyTestCase) … skipped ‘demonstrating skipping’
test_maybe_skipped (main.MyTestCase) … skipped ‘external resource not available’
test_windows_support (main.MyTestCase) … skipped ‘requires Windows’
Ran 4 tests in 0.005s
OK (skipped=4)
可以像方法一样跳过类：
@unittest.skip(“showing class skipping”)
class MySkippedTestCase(unittest.TestCase):
def test_not_run(self):
pass
TestCase.setUp()也可以跳过测试。当需要设置的资源不可用时，此功能很有用。
预期的失败使用expectedFailure()装饰器。
class ExpectedFailureTestCase(unittest.TestCase):
@unittest.expectedFailure
def test_fail(self):
self.assertEqual(1, 0, “broken”)
通过使装饰器skip()在需要跳过测试时调用测试，可以轻松滚动自己的跳过装饰器 。除非传递的对象具有特定的属性，否则此装饰器将跳过测试：
def skipUnlessHasattr(obj, attr):
if hasattr(obj, attr):
return lambda func: func
return unittest.skip("{!r} doesn’t have {!r}".format(obj, attr))
以下装饰器和异常实现了测试跳过和预期的失败：
@unittest.skip（原因）
无条件地跳过修饰的测试。 原因应说明为何跳过测试。
@unittest.skipIf（条件，原因）
如果条件为真，则跳过修饰的测试。
@unittest.skipUnless（条件，原因）
除非条件为真，否则跳过装饰性测试。
@unittest.expectedFailure
将测试标记为预期的失败或错误。如果测试失败或错误，则视为成功。如果测试通过，将被视为失败。
异常unittest.SkipTest（原因）
引发此异常以跳过测试。
通常，您可以使用TestCase.skipTest()或跳过装饰器之一，而不是直接提高它。
跳过的测试将不会setUp()或不会tearDown()在它们周围运行。逃课不会有setUpClass()或tearDownClass()运行。跳过模块不会有setUpModule()或tearDownModule()运行。
使用子测试区分测试迭代
3.4版的新功能。
如果您的测试之间的差异非常小（例如某些参数），则unittest允许您使用subTest()上下文管理器在测试方法的内部区分它们。
例如，以下测试：
class NumbersTest(unittest.TestCase):
def test_even(self):
"""
Test that numbers between 0 and 5 are all even.
"""
for i in range(0, 6):
with self.subTest(i=i):
self.assertEqual(i % 2, 0)
将产生以下输出：
FAIL: test_even (main.NumbersTest) (i=1)
Traceback (most recent call last):
File “subtests.py”, line 32, in test_even
self.assertEqual(i % 2, 0)
AssertionError: 1 != 0
======================================================================
FAIL: test_even (main.NumbersTest) (i=3)
Traceback (most recent call last):
File “subtests.py”, line 32, in test_even
self.assertEqual(i % 2, 0)
AssertionError: 1 != 0
======================================================================
FAIL: test_even (main.NumbersTest) (i=5)
Traceback (most recent call last):
File “subtests.py”, line 32, in test_even
self.assertEqual(i % 2, 0)
AssertionError: 1 != 0
如果不使用子测试，则在第一次失败后执行将停止，并且错误将不那么容易诊断，因为i 将不会显示的值：
FAIL: test_even (main.NumbersTest)
Traceback (most recent call last):
File “subtests.py”, line 32, in test_even
self.assertEqual(i % 2, 0)
AssertionError: 1 != 0
类和函数
本节深入介绍的API unittest。
测试用例
类unittest.TestCase（methodName =‘runTest’ ）
TestCase该类的实例表示unittestUniverse中的逻辑测试单元。该类旨在用作基类，具体测试由具体的子类实现。此类实现测试运行程序所需的接口，以使其能够驱动测试，以及测试代码可用于检查和报告各种故障的方法。
的每个实例都TestCase将运行一个基本方法：名为methodName的方法。在的大多数用法中TestCase，您既不会更改methodName也不会重新实现默认runTest()方法。
在版本3.2中更改：TestCase可以成功实例化，而无需提供 methodName。这样可以更轻松地TestCase 从交互式解释器进行实验。
TestCase 实例提供三组方法：一组用于运行测试，另一组由测试实现用于检查条件和报告故障，还有一些查询方法允许收集有关测试本身的信息。
第一组（运行测试）的方法是：
setUp（）
调用准备测试夹具的方法。这是在调用测试方法之前立即调用的；除了AssertionError或SkipTest之外，此方法引发的任何异常都将被视为错误而不是测试失败。默认实现不执行任何操作。
tearDown（）
调用测试方法并记录结果后立即调用的方法。即使测试方法引发异常，也会调用此方法，因此在子类中的实现可能需要特别注意检查内部状态。此方法引发的任何异常（AssertionError或除外） SkipTest都将被视为附加错误，而不是测试失败（因此将增加报告的错误总数）。setUp()无论测试方法的结果如何，仅在成功的情况下才调用此方法。默认实现不执行任何操作。
setUpClass（）
在运行单个类中的测试之前调用的类方法。 setUpClass以类作为唯一参数调用，并且必须修饰为classmethod()：
@classmethod
def setUpClass(cls):
…
有关更多详细信息，请参见类和模块装置。
3.2版中的新功能。
tearDownClass（）
在单个类中的测试运行后调用的类方法。 tearDownClass以类作为唯一参数调用，并且必须修饰为classmethod()：
@classmethod
def tearDownClass(cls):
…
有关更多详细信息，请参见类和模块装置。
3.2版中的新功能。
run（result = None ）
运行测试，将结果收集到TestResult作为result传递的对象中。如果省略result或None，则将创建临时结果对象（通过调用该defaultTestResult() 方法）并将其使用。结果对象返回给run()的调用者。
通过简单地调用TestCase 实例，可以达到相同的效果。
在3.3版中进行了更改：的早期版本run未返回结果。都没有调用实例。
skipTest（原因）
在测试方法期间调用此方法或setUp()跳过当前测试。有关更多信息，请参见跳过测试和预期的失败。
3.1版中的新功能。
subTest（msg = None，** params ）
返回一个上下文管理器，该上下文管理器将附带的代码块作为子测试执行。 msg和params是可选的，任意值，在子测试失败时会显示这些值，使您可以清楚地识别它们。
一个测试用例可以包含任意数量的子测试声明，并且它们可以任意嵌套。
有关更多信息，请参见使用子测试区分测试迭代。
3.4版的新功能。
debug（）
运行测试而不收集结果。这允许将测试引发的异常传播到调用方，并可以用于支持在调试器下运行测试。
本TestCase类提供了一些断言方法来检查并报告故障。下表列出了最常用的方法（有关更多断言方法，请参见下表）：
方法 检查 新进
assertEqual(a, b) a == b
assertNotEqual(a, b) a != b
assertTrue(x) bool(x) is True
assertFalse(x) bool(x) is False
assertIs(a, b) a is b 3.1
assertIsNot(a, b) a is not b 3.1
assertIsNone(x) x is None 3.1
assertIsNotNone(x) x is not None 3.1
assertIn(a, b) a in b 3.1
assertNotIn(a, b) a not in b 3.1
assertIsInstance(a, b) isinstance(a, b) 3.2
assertNotIsInstance(a, b) not isinstance(a, b) 3.2
所有的assert方法都接受一个msg参数，如果指定了该参数，该参数将用作失败时的错误消息（另请参见longMessage）。请注意，味精关键字参数可以传递给assertRaises()， assertRaisesRegex()，assertWarns()，assertWarnsRegex() 只有当它们被用作上下文管理器。
assertEqual（第一，第二，msg = None ）
测试第一和第二是否相等。如果值比较不相等，则测试将失败。
此外，如果first和second是完全相同的类型，并且将调用list，tuple，dict，set，frozenset或str或子类addTypeEqualityFunc()在特定于类型的相等性函数中注册的任何类型中的一个，以便生成更有用的默认错误消息（另请参见类型特定方法的列表）。
在版本3.1中进行了更改：添加了自动调用特定于类型的相等函数的功能。
在3.2版中进行了更改：assertMultiLineEqual()添加为用于比较字符串的默认类型相等函数。
assertNotEqual（第一，第二，msg = None ）
测试第一个和第二个不相等。如果这些值确实比较相等，则测试将失败。
assertTrue（expr，msg = None ）
assertFalse（expr，msg = None ）
测试expr为true（或false）。
请注意，这等效于（而不是等效于）（用于后者）。当有更具体的方法可用时（例如代替），也应避免使用此方法 ，因为在发生故障的情况下，它们可以提供更好的错误消息。bool(expr) is Trueexpr is TrueassertIs(expr, True)assertEqual(a, b)assertTrue(a == b)
assertIs（第一，第二，msg = None ）
assertIsNot（第一，第二，msg = None ）
测试第一个和第二个是（或不是）相同的对象。
3.1版中的新功能。
assertIsNone（expr，msg = None ）
assertIsNotNone（expr，msg = None ）
测试expr是（或不是）None。
3.1版中的新功能。
assertIn（member，container，msg = None ）[源代码）
assertNotIn（member，container，msg = None ）[源代码）
测试成员是否在container中。
3.1版中的新功能。
assertIsInstance（obj，cls，msg = None ）
assertNotIsInstance（obj，cls，msg = None ）
测试obj是（或不是）cls的实例（可以是类或类的元组，如所支持isinstance()）。要检查确切的类型，请使用。assertIs(type(obj), cls)
3.2版中的新功能。
也可以使用以下方法检查异常，警告和日志消息的产生：
方法 检查 新进
assertRaises(exc, fun, *args, **kwds) fun(*args, **kwds)提高EXC
assertRaisesRegex(exc, r, fun, *args, **kwds) fun(*args, **kwds)引发EXC ，并且消息与正则表达式R匹配 3.1
assertWarns(warn, fun, *args, **kwds) fun(*args, **kwds)提出警告 3.2
assertWarnsRegex(warn, r, fun, args, **kwds) fun(args, kwds)引发警告 ，并且消息与正则表达式r匹配 3.2
assertLogs(logger, level) 该with块 以最低级别登录到记录器 3.4
assertRaises（exception，callable， args， kwds ）源代码）
assertRaises（例外，，msg = None ）
测试是否使用还会传递给的任何位置或关键字参数 调用callable时引发了异常assertRaises()。如果引发异常，则测试通过；如果引发另一个异常，则测试通过；如果未引发异常，则测试通过。为了捕获一组异常中的任何一个，可以将包含异常类的元组作为exception传递。
如果仅给出异常和可能的msg参数，则返回一个上下文管理器，以便可以将内嵌代码而不是作为函数编写被测代码：
with self.assertRaises(SomeException):
do_something()
当用作上下文管理器时，assertRaises()接受附加的关键字参数msg。
上下文管理器会将捕获的异常对象存储在其 exception属性中。如果要对引发的异常执行其他检查，这将很有用：
with self.assertRaises(SomeException) as cm:
do_something()
the_exception = cm.exception
self.assertEqual(the_exception.error_code, 3)
在版本3.1中进行了更改：添加了assertRaises()用作上下文管理器的功能。
在版本3.2中更改：添加了exception属性。
在版本3.3中进行了更改：在用作上下文管理器时，添加了msg关键字参数。
assertRaisesRegex（exception，regex，callable，* args，** kwds ）
assertRaisesRegex（exception，regex，，msg = None ）
像assertRaises()但也测试正则表达式是否与引发的异常的字符串表示形式匹配。 regex可以是正则表达式对象，也可以是包含适用于的正则表达式的字符串re.search()。例子：
self.assertRaisesRegex(ValueError, "invalid literal for.XYZ’$",
int, ‘XYZ’)
或者：
with self.assertRaisesRegex(ValueError, ‘literal’):
int(‘XYZ’)
3.1版中的新功能：在名称下添加assertRaisesRegexp。
在版本3.2中更改：重命名为assertRaisesRegex()。
在版本3.3中进行了更改：在用作上下文管理器时，添加了msg关键字参数。
assertWarns（warning，callable， args，** kwds ）
assertWarns（警告，，msg = None ）
测试是否使用也传递给的任何位置或关键字参数 调用callable时触发了警告assertWarns()。如果警告被触发，则测试通过；否则，测试将失败。任何异常都是错误。要捕获一组警告中的任何警告，可以将包含警告类的元组作为警告传递。
如果仅给出警告和可能的msg参数，则返回一个上下文管理器，以便可以将内嵌代码而不是作为函数编写被测代码：
with self.assertWarns(SomeWarning):
do_something()
当用作上下文管理器时，assertWarns()接受附加的关键字参数msg。
上下文管理器会将捕获到的警告对象存储在其 warning属性中，并将触发警告的源代码行存储在filename和lineno属性中。如果要对捕获到的警告进行其他检查，这将很有用：
with self.assertWarns(SomeWarning) as cm:
do_something()
self.assertIn(‘myfile.py’, cm.filename)
self.assertEqual(320, cm.lineno)
无论调用该警告过滤器时该方法如何工作。
3.2版中的新功能。
在版本3.3中进行了更改：在用作上下文管理器时，添加了msg关键字参数。
assertWarnsRegex（warning，regex，callable，* args，** kwds ）
assertWarnsRegex（warning，regex，*，msg = None ）
喜欢assertWarns()但也测试正则表达式是否与触发的警告消息匹配。 regex可以是正则表达式对象，也可以是包含适用于的正则表达式的字符串re.search()。例子：
self.assertWarnsRegex(DeprecationWarning,
r’legacy_function() is deprecated’,
legacy_function, ‘XYZ’)
或者：
with self.assertWarnsRegex(RuntimeWarning, ‘unsafe frobnicating’):
frobnicate(’/etc/passwd’)
3.2版中的新功能。
在版本3.3中进行了更改：在用作上下文管理器时，添加了msg关键字参数。
assertLogs（logger = None，level = None ）
上下文管理器，用于测试至少有给定级别的消息是否在记录器或其子项中 记录了至少一条消息。
如果给出记录器，则记录器应为logging.Logger对象或 str记录器的名称。缺省值为root记录器，它将捕获未被非传播的后代记录器阻止的所有消息。
如果指定了级别，则级别应为数字日志记录级别或其等效字符串（例如"ERROR"或 logging.ERROR）。默认值为logging.INFO。
如果with 块内发出的至少一条消息符合记录器和级别条件，则测试通过，否则失败。
上下文管理器返回的对象是一个记录助手，它跟踪匹配的日志消息。它具有两个属性：
records
logging.LogRecord匹配日志消息的对象列表。
output
str具有匹配消息格式化输出的对象列表。
例子：
with self.assertLogs(‘foo’, level=‘INFO’) as cm:
logging.getLogger(‘foo’).info(‘first message’)
logging.getLogger(‘foo.bar’).error(‘second message’)
self.assertEqual(cm.output, [‘INFO:foo:first message’,
‘ERROR:foo.bar:second message’])
3.4版的新功能。
还有其他用于执行更具体检查的方法，例如：
方法 检查 新进
assertAlmostEqual(a, b) round(a-b, 7) == 0
assertNotAlmostEqual(a, b) round(a-b, 7) != 0
assertGreater(a, b) a > b 3.1
assertGreaterEqual(a, b) a >= b 3.1
assertLess(a, b) a < b 3.1
assertLessEqual(a, b) a <= b 3.1
assertRegex(s, r) r.search(s) 3.1
assertNotRegex(s, r) not r.search(s) 3.2
assertCountEqual(a, b) a和b具有相同编号的相同元素，而不管其顺序如何。 3.2
assertAlmostEqual（first，second，places = 7，msg = None，delta = None ）
assertNotAlmostEqual（first，second，places = 7，msg = None，delta = None ）
测试第一和第二近似（或不近似）通过计算差，舍入到给定数目的小数等于地方（默认7），并与零进行比较。请注意，这些方法将值四舍五入到给定的小数位数（即round()函数），而不是有效数字。
如果提供了delta而不是place，则第一和第二个之间的差必须小于或等于（或大于）delta。
提供三角洲和地方都会产生一个TypeError。
在版本3.2中更改：assertAlmostEqual()自动考虑比较相等的几乎相等的对象。 assertNotAlmostEqual()如果对象比较相等，则自动失败。添加了delta关键字参数。
assertGreater（第一，第二，msg = None ）
assertGreaterEqual（第一，第二，msg = None ）
assertLess（第一，第二，msg = None ）
assertLessEqual（第一，第二，msg = None ）
测试第一个分别是>，> =，<或<=比第二个要多，具体取决于方法名称。如果不是，则测试将失败：
self.assertGreaterEqual(3, 4)
AssertionError: “3” unexpectedly not greater than or equal to “4”
3.1版中的新功能。
assertRegex（text，regex，msg = None ）
assertNotRegex（text，regex，msg = None ）
测试正则表达式搜索匹配（或不匹配）text。如果失败，错误消息将包括模式和文本（或模式和文本中意外匹配的部分）。 regex 可以是正则表达式对象，也可以是包含适用于的正则表达式的字符串re.search()。
3.1版中的新功能：在名称下添加assertRegexpMatches。
在版本3.2中更改：方法assertRegexpMatches()已重命名为 assertRegex()。
版本3.2中的新功能：assertNotRegex()。
版本3.5中的新功能：该名称assertNotRegexpMatches是不推荐使用的别名assertNotRegex()。
assertCountEqual（第一，第二，msg = None ）
测试第一个序列是否包含与第二个相同的元素，而不管它们的顺序如何。否则，将生成一条错误消息，列出序列之间的差异。
比较first和 second时，不会忽略重复的元素。它验证两个序列中每个元素的计数是否相同。等效于： 但也适用于不可哈希对象的序列。assertEqual(Counter(list(first)), Counter(list(second)))
3.2版中的新功能。
该assertEqual()方法将相同类型的对象的相等性检查分派给不同的特定于类型的方法。这些方法已经为大多数内置类型实现，但是也可以使用addTypeEqualityFunc()以下方法注册新方法：
addTypeEqualityFunc（typeobj，function ）
注册一种特定于类型的方法，该方法称为，assertEqual()以检查两个完全相同的typeobj（不是子类）的对象是否相等。 函数必须采用两个位置参数和第三个msg = None关键字参数，就像这样assertEqual()做一样。self.failureException(msg)当检测到前两个参数之间的不平等时，它必须提高 -可能提供有用的信息并在错误消息中详细解释不平等。
3.1版中的新功能。
assertEqual()下表总结了自动使用的特定于类型的方法 的列表。请注意，通常不必直接调用这些方法。
方法 用于比较 新进
assertMultiLineEqual(a, b) 弦乐 3.1
assertSequenceEqual(a, b) 顺序 3.1
assertListEqual(a, b) 清单 3.1
assertTupleEqual(a, b) 元组 3.1
assertSetEqual(a, b) 集或冻结集 3.1
assertDictEqual(a, b) 字典 3.1
assertMultiLineEqual（第一，第二，msg = None ）
测试多行字符串first等于第二字符串。当不相等时，突出显示差异的两个字符串的差异将包含在错误消息中。在将字符串与进行比较时，默认使用此方法assertEqual()。
3.1版中的新功能。
assertSequenceEqual（第一，第二，msg = None，seq_type = None ）
测试两个序列是否相等。如果提供了seq_type，则 第一和第二个都必须是seq_type的实例，否则将引发故障。如果顺序不同，则会生成一条错误消息，显示两者之间的差异。
该方法不是由直接调用的assertEqual()，而是用于实现assertListEqual()和的 assertTupleEqual()。
3.1版中的新功能。
assertListEqual（第一，第二，msg = None ）
assertTupleEqual（第一，第二，msg = None ）
测试两个列表或元组是否相等。如果不是，则构造一条错误消息，仅显示两者之间的差异。如果任何一个参数的类型错误，也会引发错误。将列表或元组与进行比较时，默认使用这些方法 assertEqual()。
3.1版中的新功能。
assertSetEqual（第一，第二，msg = None ）
测试两组是否相等。如果不是，则构造一条错误消息，列出这些组之间的差异。将集或冻结集与进行比较时，默认使用此方法assertEqual()。
如果第一个或第二个都没有set.difference() 方法，则失败。
3.1版中的新功能。
assertDictEqual（第一，第二，msg = None ）
测试两个字典是否相等。如果不是，则构造一条错误消息，显示字典中的差异。默认情况下，将使用此方法比较对的调用中的字典assertEqual()。
3.1版中的新功能。
最后，TestCase提供以下方法和属性：
fail（msg = None ）
使用msg或None错误消息无条件地发出测试失败的信号。
failureException
此类属性给出了test方法引发的异常。如果测试框架需要使用特殊的异常（可能带有其他信息），则它必须将该异常子类化，以便与框架“公平竞争”。此属性的初始值为 AssertionError。
longMessage
此类属性确定将自定义失败消息作为msg参数传递给失败的assertXYY调用时发生的情况。 True是默认值。在这种情况下，自定义消息将附加到标准失败消息的末尾。设置False为时，自定义消息将替换标准消息。
通过在调用assert方法之前True或False之后分配实例属性self.longMessage，可以在各个测试方法中覆盖类设置。
在每次测试调用之前，将重置班级设置。
3.1版中的新功能。
maxDiff
此属性控制通过报告故障时差异的assert方法来控制差异输出的最大长度。默认为80 * 8个字符。受此属性影响的断言方法是 assertSequenceEqual()（包括委托给它的所有序列比较方法）assertDictEqual()和 assertMultiLineEqual()。
设置maxDiff为None表示没有最大差异长度。
3.2版中的新功能。
测试框架可以使用以下方法来收集有关测试的信息：
countTestCases（）
返回此测试对象表示的测试数量。对于 TestCase情况下，这将永远是1。
defaultTestResult（）
返回应用于此测试用例类的测试结果类的实例（如果未向该run()方法提供其他结果实例 ）。
对于TestCase情况下，这将永远是一个实例 TestResult; 的子类TestCase应在必要时覆盖此方法。
id（）
返回标识特定测试用例的字符串。这通常是测试方法的全名，包括模块和类名。
shortDescription（）
返回测试的描述，或者None没有提供描述。此方法的默认实现返回测试方法docstring的第一行（如果有），或None。
在版本3.1中进行了更改：在3.1中进行了更改，即使在存在文档字符串的情况下，也将测试名称添加到简短描述中。这导致与unittest扩展的兼容性问题，并且将测试名称添加到了 TextTestResultPython 3.2中。
addCleanup（函数，/，* args，** kwargs ）
添加一个在之后调用的函数，tearDown()以清理测试期间使用的资源。将以与添加功能相反的顺序调用这些功能（LIFO）。它们addCleanup()被添加时添加的任何参数和关键字参数调用 。
如果setUp()失败（表示tearDown()未调用），则仍将调用添加的任何清理函数。
3.1版中的新功能。
doCleanups（）
在tearDown()或在setUp()ifsetUp()引发异常之后无条件调用此方法。
它负责调用所添加的所有清除函数 addCleanup()。如果你需要清除函数被调用 之前到tearDown()，那么你可以调用doCleanups() 自己。
doCleanups() 一次将方法从清除函数堆栈中弹出一次，因此可以随时调用它。
3.1版中的新功能。
classmethod addClassCleanup（函数，/，* args，** kwargs ）
添加一个在之后要调用的函数，tearDownClass()以清理测试类中使用的资源。将以与添加功能相反的顺序调用这些功能（LIFO）。它们addClassCleanup()被添加时添加的任何参数和关键字参数调用 。
如果setUpClass()失败（表示tearDownClass()未调用），则仍将调用添加的所有清理函数。
3.8版中的新功能。
classmethod doClassCleanups（）
在tearDownClass()或在setUpClass()ifsetUpClass()引发异常之后无条件调用此方法。
它负责调用所添加的所有清除函数 addClassCleanup()。如果你需要清除函数被调用 之前到tearDownClass()，那么你可以调用 doClassCleanups()自己。
doClassCleanups() 一次将方法从清除函数堆栈中弹出一次，因此可以随时调用它。
3.8版中的新功能。
类unittest.IsolatedAsyncioTestCase（methodName =‘runTest’ ）
此类提供类似于API的API，TestCase并且还接受协程作为测试函数。
3.8版中的新功能。
协程asyncSetUp（）
调用准备测试夹具的方法。这被称为after setUp()。这是在调用测试方法之前立即调用的；除了 AssertionError或SkipTest之外，此方法引发的任何异常都将被视为错误而不是测试失败。默认实现不执行任何操作。
协程asyncTearDown（）
调用测试方法并记录结果后立即调用的方法。这被称为之前tearDown()。即使测试方法引发异常，也会调用此方法，因此在子类中的实现可能需要特别注意检查内部状态。此方法引发的任何异常（AssertionError或除外） SkipTest都将被视为附加错误，而不是测试失败（因此将增加报告的错误总数）。asyncSetUp()无论测试方法的结果如何，仅在成功的情况下才调用此方法。默认实现不执行任何操作。
addAsyncCleanup（函数，/，* args，** kwargs ）
此方法接受可以用作清理功能的协程。
run（result = None ）
设置一个新的事件循环以运行测试，将结果收集到TestResult作为result传递的对象中。如果省略result或None，则将创建临时结果对象（通过调用该defaultTestResult()方法）并将其使用。结果对象返回给run()的调用者。测试结束时，事件循环中的所有任务都将被取消。
一个说明顺序的示例：
from unittest import IsolatedAsyncioTestCase
events = []
class Test(IsolatedAsyncioTestCase):
def setUp(self):
events.append("setUp")
async def asyncSetUp(self):
self._async_connection = await AsyncConnection()
events.append("asyncSetUp")
async def test_response(self):
events.append("test_response")
response = await self._async_connection.get("https://example.com")
self.assertEqual(response.status_code, 200)
self.addAsyncCleanup(self.on_cleanup)
def tearDown(self):
events.append("tearDown")
async def asyncTearDown(self):
await self._async_connection.close()
events.append("asyncTearDown")
async def on_cleanup(self):
events.append("cleanup")
if name == “main”:
unittest.main()
运行测试后，events将包含。[“setUp”, “asyncSetUp”, “test_response”, “asyncTearDown”, “tearDown”, “cleanup”]
类unittest.FunctionTestCase（testFunc，setUp = None，tearDown = None，description = None ）
此类实现了TestCase接口的一部分，该部分允许测试运行程序进行测试，但不提供测试代码可用于检查和报告错误的方法。它用于使用遗留测试代码创建测试用例，从而将其集成到 unittest基于测试的框架中。
弃用的别名
由于历史原因，某些TestCase方法具有一个或多个别名，现在不建议使用。下表列出了正确的名称及其不赞成使用的别名：
方法名称 弃用的别名 弃用的别名
assertEqual() 失败等于 断言等于
assertNotEqual() failIfEqual assertNotEquals
assertTrue() 除非失败 断言_
assertFalse() 如果失败
assertRaises() failUnlessRaises
assertAlmostEqual() failUnlessAlmostEqual assertAlmostEquals
assertNotAlmostEqual() failIfAlmostEqual assertNotAlmostEquals
assertRegex() assertRegexpMatches
assertNotRegex() assertNotRegexpMatches
assertRaisesRegex() assertRaisesRegexp
从版本3.1开始不推荐使用：第二列中列出的fail *别名已被弃用。
从版本3.2开始不推荐使用：第三列中列出的assert *别名已被弃用。
从3.2版开始弃用：assertRegexpMatches，assertRaisesRegexp并且已重命名为 assertRegex()和assertRaisesRegex()。
自从3.5版本不推荐使用：该assertNotRegexpMatches名赞成不赞成assertNotRegex()。
分组测试
类unittest.TestSuite（tests =（））
此类表示各个测试用例和测试套件的集合。该类提供测试运行程序所需的接口，以使其能够像其他任何测试用例一样运行。运行TestSuite实例与遍历套件（分别运行每个测试）相同。
如果给出了测试，则它必须是单个测试用例或其他最初用于构建套件的测试套件的可迭代项。稍后提供了其他方法来将测试用例和套件添加到集合中。
TestSuite对象的行为与TestCase对象非常相似，不同之处在于它们实际上并未实现测试。相反，它们用于将测试聚合到应一起运行的测试组中。可以使用一些其他方法将测试添加到TestSuite实例：
addTest（测试）
在套件中添加TestCase或TestSuite。
addTests（测试）
将来自所有可迭代的TestCase和TestSuite 实例的测试添加到该测试套件中。
这等效于遍历测试，调用addTest()每个元素。
TestSuite与以下人员共享以下方法TestCase：
run（结果）
运行与此套件相关的测试，将结果收集到作为result传递的测试结果对象中。请注意，不同于 TestCase.run()，TestSuite.run()需要传递结果对象。
debug（）
运行与此套件关联的测试，而不收集结果。这允许将测试引发的异常传播到调用方，并可用于支持在调试器下运行测试。
countTestCases（）
返回此测试对象表示的测试数量，包括所有单个测试和子套件。
iter（）
由a分组的测试TestSuite始终通过迭代来访问。子类可以通过重写懒惰地提供测试__iter__()。请注意，在单个套件上可能多次调用了此方法（例如，在对测试进行计数或比较相等性时），因此在TestSuite.run()每次调用迭代之前，重复迭代之前返回的测试必须相同。之后TestSuite.run()，除非调用者使用重写了子类TestSuite.removeTestAtIndex()以保留测试引用的方法，否则调用者不应依赖此方法返回的测试。
在3.2版中进行了更改：在较早的版本中，TestSuite直接访问的测试而不是通过迭代访问的测试，因此，覆盖__iter_()不足以提供测试。
在版本3.4中进行了更改：在早期版本中，TestSuite对TestCase后面的每个保留的引用 TestSuite.run()。子类可以通过重写来恢复该行为TestSuite._removeTestAtIndex()。
在TestSuite对象的典型用法中，该run()方法由TestRunner而不是最终用户测试工具调用。
加载和运行测试¶
类unittest.TestLoader
所述TestLoader类被用来创建从类和模块的测试套件。通常，无需创建此类的实例。该 unittest模块提供了一个实例，可以与共享 unittest.defaultTestLoader。但是，使用子类或实例可以自定义一些可配置的属性。
TestLoader 对象具有以下属性：
errors
加载测试时遇到的非致命错误的列表。加载程序在任何时候都不会重置。致命错误由相关的方法发出信号，该方法向调用方引发异常。非致命错误还可以通过综合测试来表示，该综合测试会在运行时引发原始错误。
3.5版的新功能。
TestLoader 对象具有以下方法：
loadTestsFromTestCase（testCaseClass ）
返回一个套件中包含的所有测试用例TestCase派生 testCaseClass。
将为每个由命名的方法创建一个测试用例实例 getTestCaseNames()。默认情况下，这些是以开头的方法名称test。如果不getTestCaseNames()返回任何方法，但是runTest()实现了该方法，则将为该方法创建一个测试用例。
loadTestsFromModule（module，pattern = None ）
返回给定模块中包含的所有测试用例的套件。此方法在模块中搜索从TestCase该类派生的类，并为为该类定义的每个测试方法创建该类的实例。
笔记
虽然使用TestCase派生类的层次结构可以方便地共享固定装置和辅助函数，但是在不打算直接实例化的基类上定义测试方法不适用于此方法。但是，当固定装置不同且在子类中定义时，这样做可能会很有用。
如果模块提供了load_tests功能，则将调用该模块以加载测试。这允许模块自定义测试加载。这是load_tests协议。的图案参数作为第三个参数来传递load_tests。
在版本3.2中更改：load_tests增加了对的支持。
在版本3.5中进行了更改：不推荐使用非官方的，非官方的use_load_tests默认参数，尽管该参数仍为向后兼容而被接受。该方法现在还接受仅关键字的参数 模式，该模式将load_tests作为第三个参数传递给。
loadTestsFromName（name，module = None ）
给定一个字符串说明符，返回所有测试用例的套件。
指定者名称是“点分名称”，可以解析为模块，测试用例类，测试用例类中的测试方法， TestSuite实例或返回TestCase或TestSuite实例的可调用对象 。这些检查按照此处列出的顺序进行；也就是说，可能的测试用例类上的方法将被选择为“测试用例类内的测试方法”，而不是“可调用对象”。
例如，如果您有一个模块，该模块SampleTests包含带有三个测试方法（，和）的 TestCase-derived类，则说明符将导致此方法返回一个套件，该套件将运行所有三个测试方法。使用说明符 将导致它返回一个仅运行测试方法的测试套件。该说明符可以引用尚未导入的模块和包。它们将作为副作用导入。SampleTestCasetest_one()test_two()test_three()‘SampleTests.SampleTestCase’‘SampleTests.SampleTestCase.test_two’test_two()
该方法可选地解析相对于给定模块的名称。
在版本3.5中更改：如果遍历名称时出现 ImportError或，则将返回在运行时引发该错误的综合测试。这些错误包括在self.errors累积的错误中。AttributeError
loadTestsFromNames（names，module = None ）[源代码）
与相似loadTestsFromName()，但采用一系列名称而不是单个名称。返回值是一个测试套件，它支持为每个名称定义的所有测试。
getTestCaseNames（testCaseClass ）
返回在testCaseClass中找到的方法名称的排序序列；这应该是的子类TestCase。
discover（start_dir，pattern =‘test * .py’，top_level_dir = None ）
通过从指定的起始目录递归到子目录中，找到所有测试模块，然后返回包含它们的TestSuite对象。仅加载与模式匹配的测试文件。（使用外壳样式模式匹配。）将仅加载可导入的模块名称（即有效的Python标识符）。
所有测试模块必须可从项目的顶层导入。如果起始目录不是顶级目录，则必须单独指定顶级目录。
如果导入模块失败，例如由于语法错误，则将其记录为单个错误，并且发现将继续。如果由于导入失败而引起导入失败SkipTest，则将其记录为跳过而不是错误。
如果找到软件包（包含名为的文件的目录__init__.py），则将检查该软件包的load_tests功能。如果存在，则将其调用 。测试发现要小心确保即使在load_tests函数本身调用的情况下，在调用过程中仅对程序包检查一次测试 。package.load_tests(loader, tests, pattern)loader.discover
如果load_tests存在，那么发现并没有递归放入包中，load_tests负责加载包中的所有测试。
故意不将模式存储为loader属性，以便程序包可以自己继续发现。top_level_dir已存储，因此 load_tests不需要将此参数传递给 loader.discover()。
start_dir可以是点分模块名称以及目录。
3.2版中的新功能。
在版本3.4中进行了更改：SkipTest导入时引发的模块记录为跳过而不是错误。
在版本3.4中更改：start_dir可以是名称空间包。
在版本3.4中进行了更改：在导入之前对路径进行了排序，因此即使基础文件系统的顺序不依赖于文件名，执行顺序也相同。
在版本3.5中进行了更改：现在load_tests，无论其路径是否与pattern匹配，都将检查找到的程序包，因为程序包名称不可能与默认模式匹配。
TestLoader可以通过实例的子类化或分配来配置a的以下属性：
testMethodPrefix
字符串，提供方法名称的前缀，该名称将被解释为测试方法。默认值为’test’。
这会影响getTestCaseNames()所有loadTestsFrom*() 方法。
sortTestMethodsUsing
在对方法名称getTestCaseNames()和所有loadTestsFrom*()方法进行排序时用于比较方法名称的函数 。
suiteClass
从测试列表构造测试套件的可调用对象。在结果对象上不需要任何方法。默认值为 TestSuiteclass。
这会影响所有loadTestsFrom*()方法。
testNamePatterns
测试套件中必须包含测试方法必须匹配的Unix Shell样式通配符测试名称模式的列表（请参阅-v选项）。
如果此属性不是None（默认），则要包含在测试套件中的所有测试方法必须与该列表中的模式之一匹配。请注意，匹配始终使用进行fnmatch.fnmatchcase()，因此与传递给该-v选项的模式不同，必须使用通配符转换简单的子字符串模式。
这会影响所有loadTestsFrom()方法。
3.7版中的新功能。
类unittest.TestResult
此类用于编译有关哪些测试成功和哪些失败的信息。
一个TestResult对象存储一组测试的结果。在 TestCase和TestSuite班保证结果正确记录; 测试作者无需担心记录测试结果。
建立在之上的测试框架unittest可能希望访问TestResult通过运行一组测试生成的 对象以生成报告。为此TestResult，TestRunner.run()方法返回一个实例 。
TestResult 实例具有以下属性，这些属性在检查运行一组测试的结果时会引起关注：
errors
包含2个元组的TestCase实例和包含格式化回溯的字符串的列表。每个元组代表一个测试，该测试引发了意外的异常。
failures
包含2个元组的TestCase实例和包含格式化回溯的字符串的列表。每个元组代表一个测试，其中使用TestCase.assert*()方法明确地指示了失败。
skipped
包含2元组的TestCase实例和字符串的列表，其中包含跳过测试的原因。
3.1版中的新功能。
expectedFailures
包含2个元组的TestCase实例和包含格式化回溯的字符串的列表。每个元组代表测试用例的预期失败或错误。
unexpectedSuccesses
包含TestCase标记为预期失败但成功的实例的列表。
shouldStop
设置为何True时停止执行测试stop()。
testsRun
到目前为止，测试总数。
buffer
如果设置为true，sys.stdout并且sys.stderr将在之间进行缓冲 startTest()和stopTest()被调用。如果测试失败或错误sys.stdout，sys.stderr则仅将所收集的输出回显到实际结果中。任何输出也将附加到故障/错误消息。
3.2版中的新功能。
failfast
如果设置为true，stop()则在第一次失败或错误时将被调用，并停止测试运行。
3.2版中的新功能。
tb_locals
如果设置为true，则局部变量将在回溯中显示。
3.5版的新功能。
wasSuccessful（）
返回True如果所有的测试运行至今已经过去了，否则返回 False。
在版本3.4中更改：返回False是否有装饰器unexpectedSuccesses 标记的测试expectedFailure()。
stop（）
可以通过将此shouldStop属性设置为来调用此方法，以表明应该中止正在运行的测试集True。 TestRunner对象应遵守此标志并在不运行任何其他测试的情况下返回。
例如，TextTestRunner当用户从键盘发出中断信号时，该类将使用此功能来停止测试框架。提供TestRunner 实现的交互式工具可以类似的方式使用它。
TestResult该类的以下方法用于维护内部数据结构，并且可以在子类中扩展以支持其他报告要求。这对于在运行测试时支持交互式报告的构建工具特别有用。
startTest（测试）
在将要运行测试用例测试时调用。
stopTest（测试）
不管结果如何，在执行完测试用例测试之后调用。
startTestRun（）
在执行任何测试之前调用一次。
3.1版中的新功能。
stopTestRun（）
执行完所有测试后调用一次。
3.1版中的新功能。
addError（test，err ）
在测试用例测试引发意外异常时调用。犯错是由归国形式的元组sys.exc_info()：。(type, value, traceback)
默认实现将一个元组附加到实例的属性，其中formatted_err是从err派生的格式化回溯。(test, formatted_err)errors
addFailure（test，err ）
在测试用例测试发出失败信号时调用。犯错是由归国形式的元组sys.exc_info()：。(type, value, traceback)
默认实现将一个元组附加到实例的属性，其中formatted_err是从err派生的格式化回溯。(test, formatted_err)failures
addSuccess（测试）
在测试用例测试成功时调用。
默认实现不执行任何操作。
addSkip（测试，原因）
在跳过测试用例测试时调用。 原因是测试给出跳过的原因。
默认实现将元组附加到实例的属性。(test, reason)skipped
addExpectedFailure（test，err ）
在测试用例测试失败或错误但被expectedFailure()装饰器标记时调用。
默认实现将一个元组附加到实例的属性，其中formatted_err 是从err派生的格式化回溯。(test, formatted_err)expectedFailures
addUnexpectedSuccess（测试）
当测试用例测试用expectedFailure()装饰器标记 但成功时调用。
默认实现将测试附加到实例的 unexpectedSuccesses属性。
addSubTest（测试，子测试，结果）
子测试完成时调用。 test是与测试方法相对应的测试用例。 子测试是TestCase描述子测试的自定义 实例。
如果结果为None，则子测试成功。否则，它会失败，并有一个例外，即结果是由sys.exc_info()：返回的形式的元组。(type, value, traceback)
结果成功时，默认实现不执行任何操作，并将子测试失败记录为正常失败。
3.4版的新功能。
类unittest.TextTestResult（流，描述，冗长）
.NETTestResult使用的 具体实现TextTestRunner。
版本3.2中的新功能：此类以前被命名为_TextTestResult。旧名称仍然作为别名存在，但已被弃用。
unittest.defaultTestLoader
TestLoader打算共享的类的实例。如果不需要自定义，TestLoader则可以使用该实例，而不必重复创建新实例。
类unittest.TextTestRunner（stream = None，descriptions = True，verbosity = 1，failfast = False，buffer = False，resultclass = None，warnings = None，*，tb_locals = False ）
将结果输出到流的基本测试运行器实现。如果stream 是None，则将默认值sys.stderr用作输出流。此类具有一些可配置的参数，但本质上非常简单。运行测试套件的图形应用程序应提供替代的实现。**kwargs当将功能添加到单元测试中时，这样的实现应接受作为构造运行程序的接口的更改。
默认情况下，这个亚军显示DeprecationWarning， PendingDeprecationWarning，ResourceWarning和 ImportWarning即使他们是默认被忽略掉。由不推荐使用的unittest方法引起的不推荐使用的警告也是特殊情况，并且当警告过滤器为’default’或时’always’，它们每个模块仅出现一次，以避免出现太多警告消息。这种行为可以使用Python的覆盖-Wd或-Wa选项（见警告控制）和离开 的警告来None。
在版本3.2中更改：添加了warnings参数。
在版本3.2中更改：默认流设置为sys.stderr在实例化时间而不是导入时间。
在版本3.5中进行了更改：添加了tb_locals参数。
makeResult（）
此方法返回所TestResult使用的实例run()。它不打算直接调用，但是可以在子类中重写以提供一个custom TestResult。
makeResult()实例化在TextTestRunner构造函数中作为resultclass参数传递的类或可调用对象 。TextTestResult如果未resultclass提供，则默认为。结果类使用以下参数实例化：
stream, descriptions, verbosity
run（测试）
此方法是的主要公共接口TextTestRunner。此方法采用TestSuiteorTestCase实例。TestResult通过调用创建A ， makeResult()然后运行测试，并将结果打印到stdout。
unittest.main（模块= ’ main_’ ，defaultTest =无，argv的=无，TestRunner的=无，testLoader = unittest.defaultTestLoader，出口=真，冗长= 1，FAILFAST =无，catchbreak =无，缓冲=无，警告=无）
一个命令行程序，它从模块加载一组测试并运行它们；这主要是为了使测试模块方便执行。此功能最简单的用法是在测试脚本的末尾包含以下行：
if name == ‘main’:
unittest.main()
您可以通过传入verbosity参数来运行包含更详细信息的测试：
if name == ‘main’:
unittest.main(verbosity=2)
所述defaultTest参数可以是一个单一的测试的名称或可迭代测试名称如果经由未指定试验名称来运行的argv。如果未指定，或者None没有通过argv提供测试名称，则运行模块中找到的所有测试。
该argv的参数可以是传递给程序的选项列表，第一个元素是程序名称。如果未指定或None，sys.argv则使用的值。
所述的TestRunner参数可以是一个测试运行类或它的一个已创建的实例。默认情况下，带有退出代码的main调用会sys.exit()指示测试运行成功或失败。
该testLoader参数必须是一个TestLoader实例，并默认为defaultTestLoader。
main支持通过传递参数从交互式解释器中使用exit=False。这将在标准输出上显示结果，而无需调用sys.exit()：
from unittest import main
main(module=‘test_module’, exit=False)
的故障快速转移，catchbreak和缓冲参数具有与相同名称的相同的效果的命令行选项。
该警告参数指定的警告过滤器 应该在运行测试中使用。如果没有指定，它仍将None如果一个-W选项传递给蟒蛇 （见警告控制），否则将被设置为’default’。
调用main实际上返回TestProgram该类的实例。这会将测试的结果存储为result属性。
在3.1版本中更改：将退出添加参数。
在版本3.2改变：该冗长，FAILFAST，catchbreak，缓冲液 和警告加入参数。
改变在3.4版本：将defaultTest参数改为也接受一个可迭代测试名称。
load_tests协议
3.2版中的新功能。
模块或软件包可以通过实现一个名为的功能来自定义在正常测试运行或测试发现期间如何从中加载测试load_tests。
如果测试模块定义load_tests，它将通过 TestLoader.loadTestsFromModule()以下参数调用：
load_tests(loader, standard_tests, pattern)
其中图案是通过从直过去了loadTestsFromModule。默认为None。
它应该返回一个TestSuite。
loader是TestLoader执行加载的实例。 standard_tests是默认情况下将从模块中加载的测试。测试模块通常只希望在标准测试集中添加或删除测试。当加载软件包作为测试发现的一部分时，将使用第三个参数。
load_tests从一组特定的TestCase类加载测试的典型函数 可能类似于：
test_cases = (TestCase1, TestCase2, TestCase3)
def load_tests(loader, tests, pattern):
suite = TestSuite()
for test_class in test_cases:
tests = loader.loadTestsFromTestCase(test_class)
suite.addTests(tests)
return suite
如果从命令行或通过调用在包含软件包的目录中启动发现TestLoader.discover()，则将__init__.py检查软件包 load_tests。如果该功能不存在，发现将被递归到程序包中，就好像它只是另一个目录一样。否则，将通过load_tests以下参数调用对包测试的发现：
load_tests(loader, standard_tests, pattern)
这应该返回一个，TestSuite代表包装中的所有测试。（standard_tests仅包含从中收集的测试__init__.py。）
由于将模式传递到load_tests包中，因此可以自由地继续（并可能修改）测试发现。load_tests测试包的“不执行任何操作” 功能如下所示：
def load_tests(loader, standard_tests, pattern):
# top level directory cached on loader instance
this_dir = os.path.dirname(file)
package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
standard_tests.addTests(package_tests)
return standard_tests
在版本3.5中进行了更改：由于不再可能与默认模式匹配的软件包名称，发现不再检查软件包名称是否与模式匹配。
类和模块夹具
类和模块级别的固定装置在中实现TestSuite。当测试套件遇到来自新类的测试时，tearDownClass() 则从上一个类（如果有）中调用，然后setUpClass()从新类中调用 。
同样，如果测试来自与先前测试不同的模块，tearDownModule则运行来自先前模块的测试，然后 运行 setUpModule来自新模块的测试。
在所有测试都运行完之后tearDownClass，就 tearDownModule可以运行了。
请注意，共享夹具无法与测试并行化等[潜在]功能配合使用，并且会破坏测试隔离。应该小心使用它们。
unittest测试加载程序创建的测试的默认顺序是将来自相同模块和类的所有测试组合在一起。这将导致 setUpClass/ setUpModule（等）在每个类和模块中仅被调用一次。如果您将顺序随机化，以使来自不同模块和类的测试彼此相邻，则可以在一次测试运行中多次调用这些共享的夹具功能。
共享夹具不适用于非标准订购的套件。一个BaseTestSuite仍然存在不希望支持共享夹具框架。
如果在共享夹具功能之一期间引发了任何异常，则将测试报告为错误。由于没有相应的测试实例_ErrorHolder，因此TestCase创建了一个对象（与拥有相同的接口 ）来表示错误。如果您只是使用标准的单元测试测试运行程序，那么此细节并不重要，但是如果您是框架作者，则可能很重要。
setUpClass和tearDownClass
这些必须作为类方法实现：
import unittest
class Test(unittest.TestCase):
@classmethod
def setUpClass(cls):
cls._connection = createExpensiveConnectionObject()
@classmethod
def tearDownClass(cls):
cls._connection.destroy()
如果要在基类上调用setUpClass和tearDownClass，则必须自己调用它们。中的实现 TestCase为空。
如果在a期间引发了异常setUpClass，则该类中的测试将不会运行，并且tearDownClass不会运行。逃课不会有setUpClass或tearDownClass运行。如果该异常是 SkipTest异常，则该类将被报告为已跳过而不是错误。
setUpModule和tearDownModule
这些应作为功能实现：
def setUpModule():
createConnection()
def tearDownModule():
closeConnection()
如果在中引发了异常setUpModule，则模块中的任何测试都不会运行，tearDownModule也不会运行。如果异常是 SkipTest异常，则模块将被报告为已跳过而不是错误。
要添加即使在发生异常情况下也必须运行的清理代码，请使用 addModuleCleanup：
unittest.addModuleCleanup（函数，/，* args，** kwargs ）
添加一个在之后要调用的函数，tearDownModule()以清理测试类中使用的资源。将以与添加功能相反的顺序调用这些功能（LIFO）。它们addModuleCleanup()被添加时添加的任何参数和关键字参数调用 。
如果setUpModule()失败（表示tearDownModule()未调用），则仍将调用添加的所有清理函数。
3.8版中的新功能。
unittest.doModuleCleanups（）
在tearDownModule()或在setUpModule()ifsetUpModule()引发异常之后无条件调用此函数。
它负责调用所添加的所有清除函数 addCleanupModule()。如果你需要清除函数被调用 之前到tearDownModule()，那么你可以调用 doModuleCleanups()自己。
doModuleCleanups() 一次将方法从清除函数堆栈中弹出一次，因此可以随时调用它。
3.8版中的新功能。
信号处理
3.2版中的新功能。
-c/–catchunittest的命令行选项以及catchbreakto的参数unittest.main()在测试运行期间提供了对Control-C的更友好处理。启用捕获中断行为后，control-C将允许当前运行的测试完成，然后测试运行将结束并报告到目前为止的所有结果。第二个control-c将以KeyboardInterrupt通常的方式引发a 。
Control-C处理信号处理程序尝试与安装自己的signal.SIGINT处理程序的代码或测试保持兼容。如果unittest 调用了该处理程序，但不是已安装的signal.SIGINT处理程序，即已被测试系统替换并委托给该处理程序，则它将调用默认处理程序。通过替换已安装的处理程序并将其委托给它的代码，通常这将是预期的行为。对于需要unittest禁用control-c处理的单个测试，removeHandler() 可以使用装饰器。
有一些实用程序功能可供框架作者使用，以在测试框架中启用Control-C处理功能。
unittest.installHandler（）
安装control-c处理程序。当一个signal.SIGINT被接收（通常响应于用户按压控制-c）的所有已注册的结果已stop()被调用。
unittest.registerResult（结果）
注册TestResult对象以进行Control-C处理。注册结果会对其存储一个弱引用，因此不会阻止结果被垃圾收集。
TestResult如果未启用control-c处理，则注册对象没有副作用，因此测试框架可以无条件地注册其创建的所有结果，而与是否启用处理无关。
unittest.removeResult（结果）
删除注册结果。一旦删除了结果， stop()将不再响应control-c在该结果对象上调用该结果。
unittest.removeHandler（function = None ）
在不带参数的情况下调用时，此函数将删除Control-C处理程序（如果已安装）。此函数还可以用作测试装饰器，以在执行测试时临时删除处理程序：
@unittest.removeHandler
def test_signal_handling(self):
…
1343
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
