前文：
Unittest 单元测试框架1 - 基本使用和命令行选项
Unittest 单元测试框架2 - 编写测试代码以及如何跳过测试用例
Unittest 单元测试框架3 - 使用子测试区分测试迭代
Unittest 单元测试框架4 - 类与函数(1)
Unittest 单元测试框架4 - 类与函数(2)

• class unittest.IsolateAsyncioTestCase(methodName='runTest')

  3.8新版本功能

  这个类提供了一个类似于TestCase的API，并能能够接收协程作为测试函数。

  • coroutine asyncSetUp()

    该方法被用来准备test fixture。 在setUp()之后被调用。在调用测试方法之前立即被调用； 除了AssertError或SkipTest之外，此方法引发的任何异常都将被视为错误，而不是测试失败。默认实现不做任何事情。

  • coroutine asyncTearDown()
    该方法在测试方法被调用后立即调用，并记录结果。这在tearDown()之前被调用。即使测试方法引发了异常，也会调用。因此子类种的实现可能需要特别小心检查内部状态。 除了AssertError或SkipTest之外，由该方法引发的任何异常都将被视为附加错误，而不是测试失败(因此增加了报告的错误总数)。只有在asyncSetUp()成功时才会调用该方法，而不管测试方法的结果如何。默认实现不作任何事情。

  • AddAsyncCleanup(function, /, *args, **kwargs)
    该方法接收一个可用作清理函数的协程。

  • run(result=None)
    设置一个新的时间循环来运行测试，将结果收集到作为result传递的TestResult对象中， 如果result被省略或者为None。则创建一个临时的result对象(通过调用defaultTestResult()方法)并使用。result对象返回给run()的调用者。在测试结束时，事件循环中的所有任务都会被取消。

    说明顺序的一个例子:

    from unittest import IsolatedAsyncioTestCase
    import unittest
    
    
    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_reaponse", "asyncTearDown", "tearDown", "cleanup"]

• class unittest.FunctionTestCase(testFunc, setUp=None, tearDown=None, description=None)
  
  这个类实现了TestCase接口的部分，该部分允许测试运行程序驱动测试，但是没有提供测试代码可用来检查和报告错误的方法。这用于使用遗留测试代码创建测试用例，允许将其集成到基于unittest的测试框架中。

弃用别名

由于历史原因，一些TestCase方法有一个或者多个别名，现在已经弃用，下表列出来正确的名称及其弃用别名：

3.1版本已移除： The fail* alises listed in the second column have been deprecated.

3.2版本已移除： The assert* aliases listed in the third column have been deprecated.

3.2版本已移除： assertRegexpMatches and assertRaisesRegexp hava been renamed to assertRegex() and assertRaisesRegex().

3.5版本已移除： The assertNotRegexpMatches name is deprecated in favor of assertNotRegex().

分组测试

• class unittest.TestSuite(tests=())
  
  这个类表示单个测试用例和测试套件的聚合。这个类提供了测试运行程序所需的接口，以允许它像任何其他测试用例一样运行。运行TestSuite实例与在套件上迭代相同，分别运行每个测试。

  如果给出了测试，它必须是单个测试用例或最初用于构建套件的其他测试套件的可迭代对象。还提供了其他方法，以便稍后向集合中添加测试用例和套件。

  TestSuite对象的行为很像TestCase对象，除了它们实际上没有实现测试之外。相反，它们用于将测试聚合为应一起运行的测试组。一些额外的方法可以向TestSuite实例添加测试：

  • addTest(test)
    
    添加一个TestCase或者TestSuite到套件中。

  • addTests(tests)
    
    将TestCase和TestSuite实例的迭代器中所有测试添加到这个测试套件。

    这等价于遍历测试，对每个元素调用addTest().

  TestSuite和TestCase共享以下方法：

  • run(self)
    
    运行与此套件相关的测试，将结果收集到作为结果通过的测试结果对象中。注意不同于TestCase.run(), TestSuite.run()需要传入结果对象。

  • debug()
    
    运行与此套件相关的测试，但是不收集结果。这将允许将测试引发的异常传递给到调用者，并可用于支持在调试器下运行测试。

  • countTestCase()
    
    返回此测试对象表示的测试数，包括所有单独的测试和子套件。

  • iter()
    
    按TestSuite分组的测试总是通过迭代访问。子类可以通过重写__iter__()来延迟提供测试。注意，这个方法可能会在单个套件上被调用多次(例如，当计算测试数或比较相等时)，所以TestSuite.run()之前重复迭代所返回的测试对于每次调用迭代必须是相同的。在TestSuite.run()之后，调用者不应该依赖这个方法返回的测试，除非调用者使用一个覆盖TestSuite._removeTestAtIndex()的子类来保存测试引用。

    在3.2版本中更改： In earlier versions the TestSuite accessed test directly rather than through iteration so overriding iter() wasn't suffcient for providing tests.

    在3.4版本中更改： In earlier versions the TestSuite held references to each TestCase after TestSuite.run(). Subclasses can restore that behavior by overridig TestSuite._removeTestAtIndex().

  在TestSuite的经典用法中，run()方法是由TestRunner调用的，而不是由最终用户测试工具调用的。

加载和运行测试

• class unittest.TestLoader

TestLoader类用于从类和模块中创建测试套件。通常不需要创建这个类的实例， unittest模块提供了一个可以作为unittest.defaulttestloader共享的实例。然而，使用子类或实例可以定制一些可配置的属性。

  TestLoader对象具有以下属性:

  • errors

    3.5新版本功能

    加载测试时遇到的非致命错误的列表。加载程序在任何时候都不会重置。 致命错误是由调用方发出异常的相关的一个方法发出信号。

  Testloader 对象有以下方法:

  • LoadTestsFromTestCase(testCaseClass)
    
    返回一组包含在Testcase派生的testCaseClass中的所有测试用例。

    为每个由getTestCaseNames()命名的方法创建一个测试用例。默认情况下， 这些是以test开头的方法名。如果getTestCaseNames()没有返回任何方法，但是实现了runTest()方法，那么将为该方法常见单个测试用例。

  • TestsFromModule(module, pattern=None)
    
    返回给定模块中包含的所有测试用例的套件。该方法在模块中所有从TestCase派生的类，并且为该类定义的每个测试方法创建该类的实例。

    注解：再使用TestCase派生类的层次结构可以方便共享fixtures和辅助功能。在不打算直接实例化的基类上定义测试方法不适用于此方法。但是，当fixtures不同并在子类种定义时， 这样做可能很有用。

    如果模块提供了load_tests函数， 它将被调用来加载测试。这允许模块自定义加载测试。这是load_tests协议。pattern参数作为第三个参数传递给load_tests。

    3.2版本中更改： Support for load_tests added.

    3.5版本中更改： The undocumented and unofficial use_load_tests default argumentis deprecated and ignored, although it is still accepted for backward compatibility. The method also new accepts a keyword-only argument pattern which is passed to load_tests as third argument.

  • loadTestsFromName(name, module=None)
    返回一组给定字符串说明符的所有测试用例

    说明符名称是一个能够解析为模块，测试用例类，测试用例类中的测试方法， 一个TestSuite实例， 或者一个返回TestCase或者TestSuite实例的调用对象的dotted name。 这些检查是按照这里列出的顺序申请的； 也就是说一个可能的测试用例类上的方法将作为"一个测试用例类中的一个测试方法" 而不是 "一个可调用的对象" 被挑选出来。

    例如，如果你有一个模块SampleTests， 它包含一个TestCase派生的类SampleTestCase并且包含三个测试方法(test_one(), test_two()和test_three()), 则说明符SampleTests.SampleTestCase将导致该方法返回一个套件，该套件将运行所有三个测试方法。使用说明符SampleTest.SampleTestCase.test_two 将导致它返回一个只运行test_two()测试方法的测试套件。该说明符可以引用尚未导入的模块和包， 它们将被导入为side-effect.

    该方法可选地解析相对于给定模块的名称。

    3.5版本更改： If an ImportError or AttributeError occurs while traversing name then a synthetic test that raises that error when run will be returned. These error are included in the errors accumulated by self.errors.

  • loadTestsFromNames(names, module=None)
    类似于loadTestsFromName(). 但是接受一个名称序列而不是单个名称。返回值是一个测试套件， 它支持为每个名称定义的所有测试。

  • getTestCaseNames(testCaseClass)
    
    返回一个在testCaseClass中找到的方法名的排序序列。

  • discover(start_dir, pattern='test*.py', top_level_dir=None)

    3.2新版本功能

    3.4版本更改： Modules that raise SkipTest on import are recorded as skips, not errors.

    3.4版本更改： start_dir can be a namespace packages.

    3.4版本更改： Paths are sorted before being imported so that execution order is the same even if the underlying file system's ordering is not dependent on file name.

    3.5版本更改： Found packages are now checked for load_tests regardless of whether their path matches pattern, because it is impossible for a package name to match the default pattern.

    通过制定的开始目录递归到子目录中来查找所有的测试模块，并返回一个包含它们的TestSuite对象。只有匹配pattern的测试文件才会被加载。(使用shell样式模式匹配)只有可导入的模块名(即有效的Python标识符)才会被加载。

    所有的测试模块都必须可以从项目的顶层导入。如果起始目录不是顶级目录，则必须单独指定顶级目录。

    如果导入模块失败，例如由于语法错误，那么这个将被记录为单个错误，并将继续发现。如果导入失败是由于引发了SkipTest，则它将被记录为跳过而不是错误。

    如果找到一个包(包含名为__init__.py文件的目录)，将检查该包是否有load_tests函数。如果它存在，那么它将被称为package。 load_tests(loader, tests, pattern)。测试发现会确保在调用期间只检查包的测试一次，即使load_tests函数本身调用了loader,.discover。

    如果load_tests存在，则发现不会递归到包中， load_tests负责加载包中所有测试。

    该模式特意没有存储为loader属性，以便包可以继续发现自己， top_level_dir已存储，因此load_tests不需要将此参数传递给loader.discover()。

    start_dir可以是带点的模块名，也可以是目录。

  • testMethodPrefix
    
    给出将被解释为测试方法的方法名前缀的字符串。默认值为"test".

    这将影响getTestcaseNames()和所有的loadTestsFrom*()方法。

  • sortTestMethodsUsing
    
    该方法被用来在getTestCaseNames()和所有的loadTestsFrom*()排序的时候比较方法名.

  • suiteClass
    
    从测试列表构造测试套件的可调用对象。结果对象上不需要任何方法。默认值是TestSuite类。

    这将影响所有的loadTestsFrom*()方法。

  • testNamePatterns
    

    3.7版本新功能

    Unix shell风格通配符测试名模式的列表，测试方法必须匹配这些模式才能包含在测试套件中(请参阅-v选项)

    如果这个属性不是None(默认值),那么测试套件中包含的所有测试方法都必须匹配这个列表中的一个模式。注意匹配皮总是使用fnmatch.fnmatchcase()执行的，所以与传递给-v选项的模式不同，简单的子字符串模式必须使用*通配符转换。

    这将影响所有loadTestsFrom*()方法。

原文来自于https://docs.python.org/3.9/library/unittest.html#
如有侵权，请联系删除