"Objectify using Expat parser, namespace setup where needed"
import unittest, sys, cStringIO
from os.path import isfile
from gnosis.xml.objectify import make_instance, config_nspace_sep,\
XML_Objectify
BASIC, NS = 'test.xml','testns.xml'
class Prerequisite(unittest.TestCase):
def testHaveLibrary(self):
"Import the gnosis.xml.objectify library"
import gnosis.xml.objectify
def testHaveFiles(self):
"Check for sample XML files, NS and BASIC"
self.failUnless(isfile(BASIC))
self.failUnless(isfile(NS))
class ExpatTest(unittest.TestCase):
def setUp(self):
self.orig_nspace = XML_Objectify.expat_kwargs.get('nspace_sep','')
def testNoNamespace(self):
"Objectify namespace-free XML document"
o = make_instance(BASIC)
def testNamespaceFailure(self):
"Raise SyntaxError on non-setup namespace XML"
self.assertRaises(SyntaxError, make_instance, NS)
def testNamespaceSuccess(self):
"Sucessfully objectify NS after setup"
config_nspace_sep(None)
o = make_instance(NS)
def testNspaceBasic(self):
"Successfully objectify BASIC despite extra setup"
config_nspace_sep(None)
o = make_instance(BASIC)
def tearDown(self):
XML_Objectify.expat_kwargs['nspace_sep'] = self.orig_nspace
if __name__ == '__main__':
if len(sys.argv) == 1:
unittest.main()
elif sys.argv[1] in ('-q','--quiet'):
suite = unittest.TestSuite()
suite.addTest(unittest.makeSuite(Prerequisite))
suite.addTest(unittest.makeSuite(ExpatTest))
out = cStringIO.StringIO()
results = unittest.TextTestRunner(stream=out).run(suite)
if not results.wasSuccessful():
for failure in results.failures:
print "FAIL:", failure[0]
for error in results.errors:
print "ERROR:", error[0]
elif sys.argv[1].startswith('-'): # pass args to unittest
unittest.main()
else:
from gnosis.xml.objectify import pyobj_printer as show
config_nspace_sep(None)
for fname in sys.argv[1:]:
print show(make_instance(fname)).encode('UTF-8')
使用 unittest 为较简单的 doctest 方式增添了相当多的能力。我们可以将我们的测试分为几个类，每一个类都继承自 unittest.TestCase 。在每一个测试类内部，每一个名称以“.test”开始的方法都被认为是另一个测试。为 ExpatTest 定义的两个额外的类很有趣：在每次使用类执行测试前运行 .setUp() ，测试结束时运行 .tearDown() (不管测试是成功、失败还是出现错误)。在我们上面的例子中，我们为专用的 expat_kwargs 字典做了一点簿记以确保每个测试独立地运行。
顺便提一下，失败(failure)和错误(error)之间的区别很重要。一个测试可能会因为一些具体的断言无效而失败(断言方法或者以“.fail”开头，或者以“.assert”开头)。在某种意义上，失败是期望中的 -- 最起码从某种意义上我们已经具体分析过。另一方面，错误是意外的问题 -- 因为我们事先不知道哪里会出错，我们需要分析实际测试运行中的回溯来诊断这种问题。不过，我们可以设计让失败给出诊断错误的提示。例如，如果 Prerequisite.haveFiles() 失败，将在一些 TestExpat 测试中出现错误；如果前者是成功的，您将不得不到其他地方去查找错误的根源。
在 unittest.TestCase 的继承类中，具体的测试方法中可能会包括一些 .assert...() 或者 .fail...() 方法，但也可能只是具有一系列我们相信应该会成功执行的动作。如果测试方法没有按预期运行，我们将得到一个错误(以及描述这个错误的回溯)。
test_expat.py 中的 _main_ 程序块也值得察看。在最简单的情况下，我们可以只使用 unittest.main() 来运行测试用例，这将断定哪些需要运行。使用这种方式时， unittest 模块将接受一个 -v 选项以给出更详细的输出。根据指定的文件名，在执行了名称空间设置后，我们打印出指定的 XML 文件的表示，从而大致上保持了对此工具稍老版本的向后兼容。
_main_ 中最有趣的分支是期待 -q 或 --quiet 标签的那个分支。如您将期望的，除非发生失败或错误，否则这个分支将是静默的(quiet，即尽量减少输出)。不仅如此，由于它是静默的，它只会为每个问题显示一行关于失败/错误位置的报告，而不是整个诊断回溯。除了对静默输出风格的直接利用以外，这个分支还举例说明了相对于测试套件的自定义测试以及对结果报告的控制。稍微有些长的 unittest.TextTestRunner() 的默认输出被定向到 StringIO out -- 如果您想查看它，欢迎您到 out.getvalue() 去查找。不过， result 对象让我们对全面成功进行测试，如果不是完全成功还可以让我们处理失败和错误。显然，由于它们是变量中的值，您可以轻松地将 result 对象的内容记录入日志，或者在 GUI 中显示，不管怎么样，不是仅仅打印到 STDOUT。
组合测试
可能 unittest 框架最好的特性是让您可以轻松地组合包含不同模块的测试。实际上，如果使用 Python 2.3+，您甚至可以将 doctest 测试转化为 unittest 套件。让我们将到目前为止所创建的测试组合到一个脚本 test_all.py 中(诚然，说它是我们目前为止所做的测试有些夸张)：
清单 5. test_all.py 组合了单元测试
"Combine tests for gnosis.xml.objectify package (req 2.3+)"
import unittest, doctest, test_basic, test_expat
suite = doctest.DocTestSuite(test_basic)
suite.addTest(unittest.makeSuite(test_expat.Prerequisite))
suite.addTest(unittest.makeSuite(test_expat.ExpatTest))
unittest.TextTestRunner(verbosity=2).run(suite)
由于 test_expat.py 只是包含测试类，所以它们可以容易地添加到本地的测试套件中。 doctest.DocTestSuite() 函数执行文档字符串测试的转换。让我们来看看 test_all.py 运行时会做什么：
清单 6. 来自 test_all.py 的成功输出
$ python2.3 test_all.py
doctest of test_basic.show ... ok
Check for sample XML files, NS and BASIC ... ok
Import the gnosis.xml.objectify library ... ok
Raise SyntaxError on non-setup namespace XML ... ok
Sucessfully objectify NS after setup ... ok
Objectify namespace-free XML document ... ok
Successfully objectify BASIC despite extra setup ... ok
----------------------------------------------------------------------
Ran 7 tests in 0.052s
OK
注意对执行的测试的描述：在使用 unittest 测试方法的情况下，他们的描述来自于相应的 docstring 函数。如果您没有指定文档字符串，类和方法名被用作最合适的描述。来看一下如果一些测试失败时我们会得到什么，同样有趣(为本文去掉了回溯细节)：
清单 7. 当一些测试失败时的结果
$ mv testns.xml testns.xml# && python2.3 test_all.py 2>&1 | head -7
doctest of test_basic.show ... ok
Check for sample XML files, NS and BASIC ... FAIL
Import the gnosis.xml.objectify library ... ok
Raise SyntaxError on non-setup namespace XML ... ERROR
Sucessfully objectify NS after setup ... ERROR
Objectify namespace-free XML document ... ok
Successfully objectify BASIC despite extra setup ... ok
随便提及，这个失败写到 STDERR 的最后一行是“FAILED (failures=1, errors=2)”，如果您需要的话这是一个很好的总结(相对于成功时最终的“OK”)。
从这里开始
本文向您介绍了 unittest 和 doctest 的一些典型用法，它们已经改进了我自己的软件中的测试。阅读 Python 文档，以深入了解可用于测试套件、测试用例和测试结果的全部范围的方法。它们全部都遵循例子中所描述的模式。
让自己遵从 Python 的标准测试模块规定的方法学是良好的软件实践。测试驱动(test-driven)的开发在很多软件周期中都很流行；不过，显然 Python 是一门适合于测试驱动模型的语言。而且，如果只是考虑软件包更可能按计划工作，一个软件包或库如果伴随有一组周全的测试，会比缺乏这些测试的软件包或库对用户更为有用。
本文原创发布php中文网，转载请注明出处，感谢您的尊重！
相关文章
相关视频
网友评论
文明上网理性发言，请遵守 新闻评论服务协议我要评论
立即提交
专题推荐独孤九贱-php全栈开发教程
全栈 100W+
主讲：Peter-Zhu 轻松幽默、简短易学，非常适合PHP学习入门
玉女心经-web前端开发教程
入门 50W+
主讲：灭绝师太 由浅入深、明快简洁，非常适合前端学习入门
天龙八部-实战开发教程
实战 80W+
主讲：西门大官人 思路清晰、严谨规范，适合有一定web编程基础学习
949
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
