本节深入介绍了unittest的API。
8.1 测试用例Test cases相关
unittest.TestCase()
类:
用法:class unittest.TestCase(methodName='runTest')
TestCase类的实例表示unittest中的逻辑测试单元。该类旨在用作基类,具体测试由具体子类实现。TestCase类实现测试运行器所需的接口,以允许测试运行器驱动测试,并且实现测试代码可用于检查和报告各种故障的方法。
每个TestCase类的实例都会单独运行一个基本方法,这个方法叫methodName
。在TestCase的大多数用法中,既不会更改methodName,也不会重写默认的runTest()
方法。
3.2版本中的修改:可以在不提供methodName的情况下成功实例化TestCase
。这样可以更容易地从交互式解释器中试验TestCase
。
TestCase
实例提供了三组方法:一组用来运行测试,一组用来检查测试实现的检查条件和报告失败,还有一组是查询方法允许收集有关测试本身的信息。
第一组方法有:
setUP()
在准备测试脚手架时该方法被调用。在调用测试方法之前立即调用它;除了AssertionError
和SkipTest
之外,此方法抛出的任何异常都将被视为错误而非测试失败。默认实现是什么都不做。
tearDown()
调用测试方法后立即调用该方法并记录结果。即使测试方法引发异常,该方法也会被调用,因此子类中的实现可能需要特别注意检查内部状态。由此方法引发的任何异常(除了AssertionError
和SkipTest
)都将被视为额外错误,而非测试失败(从而增加报告错误的总数)。tearDown()
方法只在setUp()
方法成功时才会被调用,与测试方法的成功与否无关。默认实现是什么都不做。
setUpClass()
一个在单个类测试运行之前调用的类方法。setUpClass()
方法在被调用时使用类作为唯一参数,并且setUpClass()
方法必须被装饰成classmethod()
:
@classmethod
def setUpClass(cls):
...
阅读类和模块脚手架以获得更多信息。
新增于3.2
tearDownClass()
一个在单个类测试运行之后调用的类方法。tearDownClass()
方法在被调用时使用类作为唯一参数,并且tearDownClass()
方法必须被装饰成classmethod()
:
@classmethod
def tearDownClass(cls):
...
阅读类和模块脚手架以获得更多信息。
新增于3.2
run(result=None)
运行测试,将结果收集到作为结果传递的TestResult对象中。如果省略result或者None,则将创建临时结果对象(通过调用defaultTestResult()
方法)并使用。结果对象返回给run()
的调用者。
只需调用TestCase实例即可获得相同效果。
修改于3.3:以前版本的run()
不会返回结果,也不会调用实例。
skipTest(reason)
在测试方法或setUp()
期间调用此方法会跳过当前测试。阅读跳过测试和预期的故障已获得更多信息。
新增于3.1
subTest(msg=None, **params)
返回一个执行封闭代码块作为子测试的上下文管理器。msg
和params
是可选的,任何子测试时失败的值都会显示,允许你清楚识别它们。
测试用例可以包含任意数量的子测试声明,并且它们可以任意嵌套。
阅读使用子测试区分测试迭代以获得更多信息。
新增于3.4
debug()
运行测试而不收集结果。这个方法允许测试抛出的异常传给调用者,并可用于支持在调试器下运行测试。
TestCase类提供了几种断言方法来检查和报告失败。下表列出了最常用的方法:
Method | Checks that | New in |
---|---|---|
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()
这四个方法,仅在它们用作上下文管理器时msg关键字参数才能传递给它们。
assertEqual(first, second, msg=None)
测试first
参数和second
参数是否相等。如果值不相等,则测试将失败。
另外,如果first
和second
是完全相同的类型,并且是list、tuple、dict、set、frozenset、str或是使用addTypeEqualityFunc()
注册的子类型之一,那么将调用特定类型的相等函数以生成更有用的默认错误信息(另参见特定类型的方法列表)。
修改于3.1:增加了特定类型相等函数的自动调用。
修改于3.2:assertMultiEqual()
方法被添加为用于比较字符串的默认类型相等函数。
assertNotEqual(first, second, msg=None)
测试first
参数和second
参数是否不相等。如果值相等,则测试将失败。
assertTrue(expr, msg=None)
assertFalse(expr, msg=None)
测试expr
参数是真(或假)。
请注意,这相当于bool(expr)
为真,而不是expr
为真(expr
为真,使用assertIs(expr, True)
实现)。
assertIs(first, second, msg=None)
assertIsNot(first, second, msg=None)
测试first
参数和second
参数评定的是同一个对象或评定的不是同一个对象。
新增于3.1
assertIsNone(expr, msg=None)
assertIsNotNone(expr, msg=None)
测试expr
参数是(或不是)None。
新增于3.1
assertIn(first, second, msg=None)
assertNotIn(first, second, msg=None)
测试first
参数是(或不是)second
的子集。
新增于3.1
assertIsInstance(obj, cls, msg=None)
assertNotIsInstance(obj, cls, msg=None)
测试obj
参数是(或不是)cls
的实例(cls
可以是类或类的元祖,由isinstance()
提供支持)。要检查确切的类型,请使用assertIs(type(obj), cls)
。
新增于3.2
还可以使用以下方法检查异常、警告和日志信息的生成:
Method | Checks that | New in |
---|---|---|
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) 抛出warn
|
3.2 |
assertWarnsRegex(warn, r, fun, *args, **kwds) |
fun(*args, **kwds) 抛出warn 并且信息正则匹配r
|
3.2 |
assertLogs(logger, level) | with块使用最小level 在logger 记录日志 |
3.4 |
assertRaises(exception, callable, *args, **kwds)
assertRaises(exception, *, msg=None)
当传递位置或关键字参数来调用callable
时,如果这些参数也传递给assertRaises()
,那么测试将会抛出一个异常。如果抛出的异常为exception
,那么测试通过,如果是其他异常则为错误,如果没有抛出异常则失败。如果要捕获一组异常,可以将包含异常类的元祖作为exception
传递。
如果只给出exception
和可能的msg
参数,则返回一个上下文管理器,以便测试中的代码可以内联而不是写成函数:
with self.assertRaises(SomeException):
do_something()
当assertRaises()
被当成上下文管理器使用时,它接受额外的关键字参数msg
。
当assertRaises()
被当成上下文管理器使用时,它会将捕获的异常对象存储在它的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
与抛出的异常的字符串表示形式匹配。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(warning, *, msg=None)
测试当调用callable
的位置或关键字参数也传递给assertWarns()
时警告是否被触发。如果警告被触发则测试通过,否则测试失败。抛出任何异常都是错误。要捕获一组警告,可以将包含警告类的元祖作为warning
传递。
如果只给出warning
和可能的msg
参数,则返回一个上下文管理器,以便测试中的代码可以内联而不是写成函数:
with self.assertWarns(SomeWarning):
do_something()
当assertWarns()
被当成上下文管理器使用时,它接受额外的关键字参数msg
。
当assertWarns()
被当成上下文管理器使用时,它会将捕获的警告对象存储在它的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
与触发警告的消息匹配。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)
一个用于测试至少具有给定level
的、记录在logger
或其子节点上的消息的上下文管理器。
如果给出logger
,则logger
应该是logging.Logger
对象或是一个吉利区的名称str
。默认为根记录器,它将捕获所有消息。
如果给出level
,则level
应该是数字日志记录级别或其等效字符串(例如"ERROR"
或logging.ERROR
)。默认为logging.INFO
。
如果with
模块中至少有一条消息与logger
和level
条件匹配,则测试通过,否则失败。
上下文管理器返回的对象是一个记录助手,它记录匹配的日志消息。它有两个属性:
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。
还有其他方法用于执行更具体的检查,例如:
Method | Checks that | New in |
---|---|---|
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.2 |
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),然后将差值与0进行比较,测试 first
和second
参数是否近似相等(或不相等)。请注意,这些方法将值四舍五入到给定的小数位数(和round()
函数一样),而不是有效数字。
如果提供delta
参数而不提供places
参数,则first
和second
的差值必须小于或等于(或大于)delta
。
同时提供delta
参数和places
参数将会抛出一个TypeError
异常。
修改于3.2:assertAlmostEqual()
自动认为几乎相等的对象的比较结果是相等的。assertNotAlmostEqual()
自动失败如果两个对象比较结果相等。添加了delta
关键字参数。
assertGreater(first, second, msg=None)
assertGreaterEqual(first, second, msg=None)
assertLess(first, second, msg=None)
assertLessEqual(first, second, msg=None)
根据方法名称,分别测试first
是不是>、>=、<、<=second
。如果不是,测试将失败:
>>> 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)
测试一个regex
搜索匹配(或不匹配)text
。如果失败,错误消息将包含模式和text
(或是模式和text
中不匹配的部分)。regex
可以是正则表达式,也可以是包含适合re.search()
使用的正则表达式的字符串。
新增于3.1:使用assertRegexpMatches
作为名字。
修改于3.2:重命名为assertRegex()
。
新增于3.2:assertNotRegex()
。
新增于3.5:名字assertNotRegexpMatches
是assertNotRegex()
的弃用别名。
assertCountEqual(first, second, msg=None)
测试first
序列是否包含与second
中相同的元素,不管元素的顺序如何。如果没有,将会生成列出序列之间差异的错误消息。
比较first
和second
时,不会忽略重复的元素。assertCountEqual()
将验证每个元素在两个序列中是否具有相同的计数。相当于:assertEqual(Counter(list(first)), Counter(list(second)))
,但assertCountEqual()
也适用于不可哈希的对象列表。
新增于3.2。
assertEqual()
方法将调度对于不同类型特定的方法,相同类型的对象的相等性。这些方法已经针对大多数内置类型实现,但也可以使用addTypeEqualityFunc()
注册新方法:
addTypeEqualityFunc(typeobj, function)
注册assertEqual()
调用的特定于类型的方法,以检查完全相同的typeobj
(非子类)的两个对象是否相等。函数必须采用两个位置参数和第三个msg=None
关键字参数,就像assertEqual()
一样。当检测到前两个参数不等时抛出self.failureException(msg)
,该异常可能提供有用的信息并在错误消息中详细解释不等式。
新增于3.1。
assertEqual()
方法自动使用的特定于类型的方法列表总结在下表中。请注意,通常不必直接调用这些方法。
Method | Used to compare | New in |
---|---|---|
assertMultiLineEqual(a, b) | strings | 3.1 |
assertSequenceEqual(a, b) | sequences | 3.1 |
assertListEqual(a, b) | lists | 3.1 |
assertTupleEqual(a, b) | tuples | 3.1 |
assertSetEqual(a, b) | sets or frozensets | 3.1 |
assertDictEqual(a, b) | dicts | 3.1 |
assertMultiLineEqual(first, second, msg=None)
测试多行字符串first
等于字符串second
。当不等时,在错误信息中高亮显示两个字符串的差异。在使用assertEqual()
比较字符串时,默认使用此方法。
新增于3.1。
assertSequenceEqual(first, second, msg=None, seq_type=None)
测试两个序列是否相等。如果提供了seq_type
,则first
和second
都必须是seq_type
的实例,否则会抛出失败。如果序列不同,则在错误信息中显示两者之间的差异。
这个方法不直接被assertEqual()
调用,但是在实现assertListEqual()
和assertTupleEqual()
时被调用。
新增于3.1。
assertListEqual(first, second, msg=None)
assertTupleEqual(first, second, msg=None)
测试两个列表或元组是否相等。如果不相等,则构造一条错误消息,仅显示两者之间的差异。如果其中一个参数的类型错误,也会引发错误。在使用assertEqual()
对列表或元组进行比较时,默认使用这两个方法。
新增于3.1。
assertSetEqual(first, second, msg=None)
测试两个set是否相等。如果不相等,则构造一个错误消息,列出这两个set之间的差异。在使用assertEuqal()
对set和frozenset进行比较时,默认使用此方法。
如果first
或second
中的任何一个没有set.difference()
方法,那么就会失败。
新增于3.1。
assertDictEqual(first, second, msg=None)
测试两个字典是否相等。如果不是,则构造一条错误消息,显示字典中的差异。在使用assertEqual()
比较字典时,默认使用此方法。
新增于3.1。
最后,TestCase
类提供了下列方法和属性:
fail(msg=None)
无条件地标志测试失败,错误信息为msg
或None
。
failureException
这个类属性提供测试方法抛出的异常。如果测试框架需要使用专门的异常,比如携带额外信息的异常,那么就需要将异常子类化,以便与框架表现一致。该属性的初始值为AssertionError
。
longMessage
这个类属性决定将自定义失败消息作为msg
参数传递给assertXYY并且assertXYY失败时发生的情况。默认值为True。默认情况下,自定义消息将附加到标准故障消息的末尾。设置为False时,自定义消息将替换标准消息。
这个类设置可以在单独的测试方法中重写,只要在调用assert方法之前将实例属性self.longMessage
设定为True或False。
这个类属性在每个测试被调用时重置。
新增于3.1。
maxDiff
这属性控制assert方法在失败时输出的差异的最大长度。默认是80*8个字符。受这个属性影响的断言方法是assertSequenceEqual()
(包含所有使用它的序列比较方法)、assertDictEqual()
和assertMultiLineEqual()
。
设置maxDiff
为None
意味着对差异信息没有最大长度限制。
新增于3.2。
测试框架可以使用下列方法来收集有关测试的信息:
countTestCases()
返回这个测试对象中展示的测试数量。针对TestCase
实例,测试数量始终为1.
defaultTestResult()
返回应该用于这个测试实例类的测试结果类实例(如果没有为run()
方法提供其他结果实例)。
针对TestCase
实例,返回的将会总是一个TestResult
实例。TestCase
的子类必须重写该方法。
id()
返回标识特定测试用例的字符串。通常是测试方法的全名,包括模块名和类名。
shortDescription()
返回测试的描述,如果没有提供描述的话就返回None
。这个方法默认实现返回测试方法的文档字符串第一行(如果有的话)或者None
。
修改于3.1:在3.1中,即使存在文档字符串,也会将测试名称添加到简短描述中。这导致了unittest扩展的兼容性问题,并且在Python 3.2中,添加测试名称已经被移到了TextTestResult
中。
addCleanup(function, *args, **kwargs)
添加一个在tearDown()
之后调用的函数来清理测试期间使用的资源。函数将按添加顺序的相反顺序调用(后进先出)。在添加函数时,会使用传入addCleanup()
的任何参数和关键字参数调用这些函数。
如果setUp()
失败了,意味着tearDown()
不会被调用,但是任何已经添加的清理函数仍然会被调用。
新增于3.1。
doCleanups()
如果setUp()
抛出异常,则在tearDown()
或setUp()
之后无条件调用此方法。
这个方法负责调用addCleanup()
添加的所有清理函数。如果你需要在tearDown()
之前调用清理函数,那么你可以自行调用doCleanups()
。
doCleanups()
每次从清理函数的栈中弹出方法,因此可以随时调用它。
新增于3.1。
unittest.FunctionTestCase()
类:
用法:class unittest.FunctionTestCase(testFunc, setUp=None, tearDown=None, description=None)
该类实现了TestCase
接口的一部分,该部分允许测试运行器驱动测试,但不提供允许测试代码检查和报告错误的方法。这用于使用传统测试代码创建测试用例,允许将其集成到基于unittest的测试框架中。
8.1.1 不推荐使用的别名
因为历史原因,一些TestCase
的方法有一个或多个已经弃用的别名。下面这张表列出了正确的名称已经它们已经弃用的别名:
Method Name | Deprecated alias | Deprecated alias |
---|---|---|
assertEqual() | failUnlessEqual | assertEquals |
assertNotEqual() | failIfEqual | assertNotEquals |
assertTrue() | failUnless | assert |
assertFalse() | failIf | |
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()
中。
8.2 分组测试
unittest.TestSuite()
类:
用法:class unittest.TestSuite(tests=())
此类表示各个测试用例和测试套件的集合。该类提供了测试运行器所需的接口,以允许它像任何其他测试用例一样运行。运行一个TestSuite
实例与运行迭代套件相同,可以单独运行每个测试。
如果要给定tests
,那么它必须是一个最初将用于构建套件的可迭代的单独测试用例或其他测试套件。提供了以便稍后将测试用例和套件添加到集合中的方法。
TestSuite
对象的行为与TestCase
对象非常相似,除了TestSuite
对象没有实际实现一个测试。TestSuite
对象用于将测试聚合到应该一起运行的测试组中。可以使用一些其他方法向TestSuite
实例添加测试:
addTest(test)
添加一个TestCase
或TestSuite
到测试套件中。
addTests(tests)
添加可迭代的TestCase
和TestSuite
实例中的所有测试到测试套件中。
这相当于迭代测试,为每个元素调用addTest()
。
TestSuite
与TestCase
共享以下方法:
run(result)
运行与此套件关联的测试,收集结果作为result
传递给测试结果对象。
请注意与TestCase.run()
方法不同,TestSuite.run()
需要传入结果对象。
debug()
运行与此套件关联的测试而不收集结果。这允许测试抛出的异常传播到调用者,并可用于支持调试器下运行测试。
countTestCases()
返回这个测试对象中展示的测试数量,包括所有单独的测试和子套件。
_ _ iter _ _()
使用TestSuites
分组的测试总是通过迭代访问。子类可以通过重写__iter__()
来惰性地提供测试。请注意,这个方法可能在单个套件上调用多次(例如当统计测试或比较相等性时),因此在TestSuite.run()
之前重复迭代返回的测试对于每次调用迭代必须相同。在TestSuite.run()
之后,调用者不应该依赖此方法返回的测试,除非调用者使用重写TestSuite._removeTestAtIndex()
的子类来保留测试引用。
修改于3.2:在早期版本中,TestSuite
直接访问测试而不是通过迭代访问,因此重写__iter__()
不足以提供测试。
修改于3.4:在早期版本中,TestSuite
在TestSuite.run()
之后保存了对每个TestCase
的引用。子类可以通过重写TestSuite._removeTestAtIndex()
来恢复该行为。
在TestSuite
对象的典型用法中,run()
方法由测试运行器调用,而不是最终用户测试工具调用。
8.3 加载和运行测试
unittest.TestLoader
类:
用法:class unittest.TestLoader
TestLoader类用于从类和模块中创建测试套件。通常,不需要创建此类的实例;unittest模块提供了一个可以共享的实例unittest.defaultTestLoader
。但是,使用子类或实例可以自定义一些可配置的属性。
TestLoader
对象有下列属性:
errors
加载测试时遇到的非致命错误列表。在任何时候都不会被加载程序重置。致命错误由相关的方法发出信号,该方法向调用者抛出异常。非致命错误由综合测试指示并将在测试运行时抛出初始错误。
新增于3.5。
TestLoader
对象有下列方法:
LoadTestsFromTestCase(testCaseClass)
返回TestCase派生的testCaseClass中包含的所有测试用例的套件。
为每个以getTestCaseNames()
命名的方法创建测试用例实例。默认情况下,这些方法名字以test开头。如果getTestCaseNames()
没有返回任何方法,但是实现了runTest()
方法,则会为该方法创建一个单独的测试用例。
loadTestsFromModule(module, pattern=None)
从所有测试用例中返回一个包含给定模块的套件。这个方法从module
中搜索从TestCase
派生的类,并为该类定义的每个测试方法创建该类的实例。
注意:虽然使用TestCase派生类的层次结构可以方便地共享脚手架和帮助函数,但是在不打算直接实例化的基类上定义测试方法并不能很好地使用此方法。但是当脚手架不同并且定义在子类中时,这个方法很有用。
如果一个模块提供了一个load_tests
功能函数,那么将会在加载测试时调用该函数。这允许模块自定义测试加载。这是load_tests
协议。pattern
参数作为load_tests
的第三个参数传递。
loadTestsFromName(name, module=None)
根据给出的字符串说明符,返回包含所有测试用例的套件。
说明符name
是一个点名称,这个点名称可以解析模块、测试用例类、测试用例类中的测试方法、TestSuite实例、一个返回TestCase或TestSuite实例的可调用对象。这些检查按此处列出的顺序进行;也就是说,一个可能的测试用例类的方法将作为“测试用例类中的测试方法”而不是“可调用对象”被选中。
举个例子,有一个使用了三种测试方法(test_one()
,test_two()
,test_three()
)的TestCase派生类SampleTestCase
,如果你有一个模块SampleTests
包含了这个类,那么说明符'SampleTests.SampleTestCase.test_two
'会导致这个方法返回一个运行所有三种测试方法的套件。说明符可以引用尚未导入的模块和包;它们将作为函数副作用side-effect导入。
该方法可选地解析相对于给定module
的name
。
修改于3.5:如果在遍历name
时发生ImportError
或AttributeError
错误,则将返回在运行时引发该错误的综合测试。这些错误包含在self.errors
累积的错误中。
loadTestsFromNames(names, module=None)
与`loadTestsFromName()
网友评论