Python 中的测试框架

核心提示： 注意，我在经过改进（和扩展）的测试脚本中放入了 main 代码块，Python 中的测试框架(3)，这样，如果您在命令行中指定了 XML 文件，上面我们试过的名称空间 XML 文档 testns.xml 遇到了 EXPAT 解析器失败，由 doctest 处理的文档字符串 可能会在其内部包

注意，我在经过改进（和扩展）的测试脚本中放入了 main 代码块，这样，如果您在命令行中指定了 XML 文件，脚本将继续执行以前的行为。这样就让您可以继续分析测试用例以外其他的 XML，并只着眼于结果 -- 或者找出 gnosis.xml.objectify 所做事情中的错误，或者只是理解其目的。按标准的方式，您可以使用 -h 或 --help 参数来获得用法的说明。

当不带任何参数（或者带有只被 doctest 使用的 -v 参数）运行 test_basic.py 时，就会发现有趣的新功能。在这个例子中，我们在模块/脚本自身上运行 doctest -- 您可以看到，实际上我们将 test_basic 导入到脚本自己的名称空间中，这样我们可以简单地导入其他希望要测试的模块。 doctest.testmod() 函数去遍历模块本身、它的函数以及它的类中的所有文档字符串，以找出所有类似交互式 shell 会话的内容；在这个例子中，会在 show() 函数中找到这样一个会话。

show() 的文档字符串举例说明了在设计好的 doctest 会话过程中的几个小“陷阱（gotchas）”。不幸的是， doctest 在解析显式会话时，将空行作为会话结束来处理 -- 所以，像 pyobj_printer() 的返回值这样的输出需要加一些保护（be munged slightly）以进行测试。最简单的途径是使用文档字符串本身所定义的像 squeeze() 这样的函数（它只是除去紧跟在后面的换行）。此外，由于文档字符串毕竟是字符串换码（escape），所以 这样的序列被扩展，这样使得在代码示例 内部对换行进行换码稍微有一些混乱。您可以使用 \n ，不过我发现对 LF 的定义解决了这些问题。

在 show() 的文档字符串中定义的自测试所做的不仅是确保不发生异常（对照于最初的测试脚本）。为正确的“对象化（objectification）”至少要检查一个简单的 XML 文档。当然，仍然有可能不能正确地处理一些其他的 XML 文档 -- 例如，上面我们试过的名称空间 XML 文档 testns.xml 遇到了 EXPAT 解析器失败。由 doctest 处理的文档字符串 可能会在其内部包含回溯（traceback）,但是在特别的情况下，更好的方法是使用 unittest 。