测试.docx

1、测试1)doctest 使用doctest是一种类似于命令行尝试的方式，用法很简单，如下 复制代码 代码如下:def f(n): f(1) 1 f(2) 2 print(n) if _name_ = _main_: import doctest doctest.testmod() 应该来说是足够简单了，另外还有一种方式doctest.testfile(filename)，就是把命令行的方式放在文件里进行测试。 2)unittest unittest历史悠久，最早可以追溯到上世纪七八十年代了，C+，Java里也都有类似的实现，Python里的实现很简单。 unittest在python里主要的实

2、现方式是TestCase,TestSuite。用法还是例子起步。复制代码 代码如下:from widget import Widget import unittest # 执行测试的类 class WidgetTestCase(unittest.TestCase): def setUp(self): self.widget = Widget() def tearDown(self): self.widget.dispose() self.widget = None def testSize(self): self.assertEqual(self.widget.getSize(), (40,

3、40) def testResize(self): self.widget.resize(100, 100) self.assertEqual(self.widget.getSize(), (100, 100) # 测试 if _name_ = _main_: # 构造测试集 suite = unittest.TestSuite() suite.addTest(WidgetTestCase(testSize) suite.addTest(WidgetTestCase(testResize) # 执行测试 runner = unittest.TextTestRunner() runner.run

4、(suite)简单的说，1构造TestCase(测试用例)，其中的setup和teardown负责预处理和善后工作。2构造测试集，添加用例3执行测试需要说明的是测试方法，在Python中有N多测试函数，主要的有： TestCase.assert_(expr, msg) TestCase.failUnless(expr, msg) TestCase.assertTrue(expr, msg) TestCase.assertEqual(first, second, msg) TestCase.failUnlessEqual(first, second, msg) TestCase.assertNo

5、tEqual(first, second, msg) TestCase.failIfEqual(first, second, msg) TestCase.assertAlmostEqual(first, second, places, msg) TestCase.failUnlessAlmostEqual(first, second, places, msg) TestCase.assertNotAlmostEqual(first, second, places, msg) TestCase.failIfAlmostEqual(first, second, places, msg) TestC

6、ase.assertRaises(exception, callable, .) TestCase.failUnlessRaises(exception, callable, .) TestCase.failIf(expr, msg) TestCase.assertFalse(expr, msg) TestCase.fail(msg)最近公司进行了Python 项目测试的工作，这将意味着 Python 测试可以编写得更简洁、更统一，能够产生更好的结果报告。对于一般新入手的开发人员，如果只想在Python 项目测试或添加新特性之前检查包是否能够在他自己的平台上进行工作，那么 test_suite

7、 入口点是非常方便的，这也避免程序员多走的弯路。本文讨论先进的测试框架如何提供健壮的应用程序测试自动发现，以及这如何替代过去维护的集中式测试列表。Python 编程社区非常重视单元测试和功能性测试。这种风气不但有助于确保组件和应用程序最初的质量，还促使程序员不断调整和改进代码。本文是讨论现代 Python 测试框架的 三篇系列文章 的第二篇。本系列中的 第一篇文章 介绍了 zope.testing、py.test 和 nose，介绍它们如何影响 Python 项目编写和维护测试的方式。本文介绍如何调用这三种框架、它们如何在项目中发现测试以及如何选择并运行测试。最后一篇文章将讨论如何通过各种报告

8、特性让测试支持更强大的技术。Python 测试的黑暗时代Python 项目测试曾经是非常特殊化、个人化的活动。开发人员可能先在单独的 Python 脚本中编写每组测试。然后，编写一个名为 test_all.py 或 tests.py 的脚本，这个脚本导入并运行他的所有测试。但是，无论这个过程的自动化做得多么好，这种方式仍然是特殊化的：参与项目的每个开发人员都必须知道测试脚本放在哪里以及如何调用它们。如果某个 Python 开发人员从事十几个项目，他就必须记住十几个测试命令。test_all.py（或项目采用的其他名称）还可能手工导入所有其他测试，这可能导致风险。如果这个集中的测试列表过时了（常

9、常是由于开发人员添加了新的测试套件。手工运行它，但是忘了把它添加到中心脚本中），那么在 Python 包投入生产之前的最后一次测试就会遗漏许多测试。这种无政府状态的另一个缺点是，它要求每个测试文件包含样板代码，从而能够作为单独的命令运行。如果查看 Python 项目测试或当今的一些 Python 项目，会看到许多这样的测试示例：1. #test_old.py-Theoldwayofdoingthings 2. 3. importunittest 4. 5. classTruthTest(unittest.TestCase): 6. deftestTrue(self): 7. assertTru

10、e=1 8. 9. deftestFalse(self): 10. assertFalse=0 11. 12. if_name_=_main_: 13. unittest.main()本系列的 第一篇文章 已经讨论过基于 TestCase 类的测试在现代环境中为什么常常是不必要的。但是，现在注意最后两行：它们起什么作用？答案是，它们检测什么时候从命令行单独运行这个 test_old.py 脚本。在这种情况下，它们运行一个 unittest 简便函数，这个函数在模块中搜索测试并运行它们。它们使这个测试文件可以独立于项目范围的测试脚本单独运行。显然，在数十甚至数百个测试模块中复制相同的代码非常麻烦

11、。另一个不太明显的缺点是这种做法不利于标准化。如果 test_main() 函数不够完善，无法检测出某个模块的测试，那么这个模块的行为可能与其他测试套件不匹配。因此，每个模块在测试类的名称、操作方式和运行方式方面稍有差异。由于主流 Python 测试框架的出现，上述的所有问题已经解决了，而且每种框架解决这些问题的方式大致相同。首先，这三种测试框架都提供了从操作系统命令行运行测试的标准方法。这样，每个 Python 项目测试就不再需要在代码基中维护全局测试脚本。zope.testing 包运行测试的机制是最特殊化的：因为 Zope 开发人员常常使用 buildout 设置他们的项目，常常通过 b

12、uildout.cfg 文件中的 zc.recipe.testrunner recipe 安装测试脚本。但是，结果在不同的项目上相当一致：在我遇到的每个 Zope 项目中，开发 buildout 都会创建一个 ./bin/test 脚本，可以通过它调用项目的测试。py.test 和 nose 项目的做法更意思。它们都提供一个命令行工具，所以每个项目完全不需要有自己的测试命令：14. #Runpy.testontheproject 15. #inthecurrentdirectory. 16. 17. $py.test 18. 19. #Runnoseontheproject 20. #inth

13、ecurrentdirectory. 21. 22. $nosetestspy.test 和 nosetests 工具甚至有几个相同的命令行选项，比如 -v 选项在执行测试时输出测试的名称。可能过不了多久，只要程序员熟悉这两种工具，就能够运行大多数公共 Python 包的测试可爱的 Python: Python 中的测试框架确保软件如您所愿地工作David Mertz, Ph.D. (mertzgnosis.cx), 开发人员, Gnosis Software, IncDavid Mertz 感觉脾气有些暴躁。可以通过 mertzgnosis.cx 与 David 联系，也可以通过他的 个人网

14、页 了解他的生活。请阅读他的 Text Processing in Python 一书。欢迎提出关于过去或将来专栏的意见和建议。 简介： 在这一期文章中，David 研究了 Python 的两个用于单元测试的标准模块： unittest 和 doctest 。这些模块扩展了用来确认函数内部的先置条件和后置条件的内置 assert 语句的能力。David 讨论了将测试融入到 Python 开发中的最好方法，同时权衡了用于不同类型项目的不同风格的优势。 本文的标签: python标记本文！发布日期：2004 年 4 月 01 日 级别：初级 访问情况1332 次浏览 建议：0(添加评论) 平均分

15、（共 1 个评分 ）我要坦白一点。尽管我是一个应用相当广泛的公共域 Python 库的创造者，但在我的模块中引入的单元测试是非常不系统的。实际上，那些测试大部分 是包括在 gnosis.xml.pickle 的 Gnosis Utilities 中的，并由该子软件包（subpackage）的贡献者所编写。我还发现，我下载的绝大多数第三方 Python 包都缺少完备的单元测试集。 不仅如此，Gnosis Utilities 中现有的测试也受困于另一个缺陷：您经常需要在极其大量的细节中去推定期望的输出，以确定测试的成败。测试实际上 - 在很多情况下 - 更像是使用库的某些部分的小实用工具。这些测试

16、（或实用工具）支持来自任意数据源（类型正确）的输入和/或描述性数据格式的输出。实际上，当您需要调试一些细微的错误时，这些测试实用工具更有用。但是对于库版本间变化的自解释的完整性检查（sanity checks）来说，这些类测试就不能胜任了。在这一期文章中，我尝试使用 Python 标准库模块 doctest 和 unittest 来改进我的实用工具集中的测试，并带领您与我一起体验（并指出一些最好的方法）。 脚本 gnosis/xml/objectify/test/test_basic.py 给出了一个关于当前测试的缺点及解决方案的典型示例。下面是该脚本的最新版本： 清单 1. test_bas

17、ic.py Read and print and objectified XML fileimport sysfrom gnosis.xml.objectify import XML_Objectify, pyobj_printerif len(sys.argv) 1: for filename in sys.argv1: for parser in (DOM,EXPAT): try: xml_obj = XML_Objectify(filename, parser=parser) py_obj = xml_obj.make_instance() print pyobj_printer(py_

18、obj).encode(UTF-8) sys.stderr.write(+ SUCCESS (using +parser+)n) print =*50 except: sys.stderr.write(+ FAILED (using +parser+)n) print =*50else: print Please specify one or more XML files to Objectify. 实用工具函数 pyobj_printer() 生成了任意 Python 对象（具体说是这样一个对象，它既没有用到 gnosis.xml.objectify 的任何其他实用工具，也没有用到 Gnos

19、is Utilities 中的 任何其他东西）的一个 非-XML 表示。在以后的版本中，我将可能会把这个函数移到 Gnosis 包内的其他地方。无论如何， pyobj_printer() 使用各种类-Python 的缩进和符号来描述对象和它们的属性（类似于 pprint ，但是扩展了实例，而不仅限于扩展内置的数据类型）。 如果一些特别的 XML 可能不能正确被地“对象化（objectified）”， test_basic.py 脚本会提供一个很好的调试工具 - 您可以可视化地查看结果对象的属性和值。此外，如果您重定向了 STDOUT，您可以查看 STDERR 上的简单消息，如这个例子中： 清单

20、 2. 分析 STDERR 结果消息 $ python test_basic.py testns.xml /dev/null+ SUCCESS (using DOM)+ FAILED (using EXPAT) 不过，上面运行的例子中对成功或失败的界定很不明显：成功只是意味着没有出现异常，而不表示（重定向的）输出 正确。 使用 doctestdoctest 模块让您可以在文档字符串（docstrings）内嵌入注释以显示各种语句的期望行为，尤其是函数和方法的结果。这样做很像是让文档字符串看起来如同一个交互式 shell 会话；完成这一任务的一个简单方法是，从一个 Python 交互式 shel

21、l 中（或者从 Idel、PythonWin、MacPython 或者其他带有交互式会话的 IDE 中）拷贝-粘贴。这一改进的 test_basic.py 脚本举例说明了自诊断功能的添加： 清单 3. 具有自诊断功能的 test_basic.py 脚本 import sysfrom gnosis.xml.objectify import XML_Objectify, pyobj_printer, EXPAT, DOMLF = ndef show(xml_src, parser): Self test using simple or user-specified XML data xml = .

22、 . . Some text about eggs. . Ode to Spam . squeeze = lambda s: s.replace(LF*2,LF).strip() print squeeze(show(xml,DOM)0) -* _XO_Spam *- Eggs PCDATA=Some text about eggs. MoreSpam PCDATA=Ode to Spam print squeeze(show(xml,EXPAT)0) -* _XO_Spam *- Eggs PCDATA=Some text about eggs. MoreSpam PCDATA=Ode to

23、 Spam PCDATA= try: xml_obj = XML_Objectify(xml_src, parser=parser) py_obj = xml_obj.make_instance() return (pyobj_printer(py_obj).encode(UTF-8), + SUCCESS (using +parser+)n) except: return (,+ FAILED (using +parser+)n)if _name_ = _main_: if len(sys.argv)=1 or sys.argv1=-v: import doctest, test_basic

24、 doctest.testmod(test_basic) elif sys.argv1 in (-h,-help,-help): print You may specify XML files to objectify instead of self-test print (Use -v for verbose output, otherwise no message means success) else: for filename in sys.argv1: for parser in (DOM, EXPAT): output, message = show(filename, parse

25、r) print output sys.stderr.write(message) print =*50 注意，我在经过改进（和扩展）的测试脚本中放入了 main 代码块，这样，如果您在命令行中指定了 XML 文件，脚本将继续执行以前的行为。这样就让您可以继续分析测试用例以外其他的 XML，并只着眼于结果 - 或者找出 gnosis.xml.objectify 所做事情中的错误，或者只是理解其目的。按标准的方式，您可以使用 -h 或 -help 参数来获得用法的说明。 当不带任何参数（或者带有只被 doctest 使用的 -v 参数）运行 test_basic.py 时，就会发现有趣的新功能。

26、在这个例子中，我们在模块/脚本自身上运行 doctest - 您可以看到，实际上我们将 test_basic 导入到脚本自己的名称空间中，这样我们可以简单地导入其他希望要测试的模块。 doctest.testmod() 函数去遍历模块本身、它的函数以及它的类中的所有文档字符串，以找出所有类似交互式 shell 会话的内容；在这个例子中，会在 show() 函数中找到这样一个会话。 show() 的文档字符串举例说明了在设计好的 doctest 会话过程中的几个小“陷阱（gotchas）”。不幸的是， doctest 在解析显式会话时，将空行作为会话结束来处理 - 所以，像 pyobj_prin

27、ter() 的返回值这样的输出需要加一些保护（be munged slightly）以进行测试。最简单的途径是使用文档字符串本身所定义的像 squeeze() 这样的函数（它只是除去紧跟在后面的换行）。此外，由于文档字符串毕竟是字符串换码（escape），所以 n 这样的序列被扩展，这样使得在代码示例 内部对换行进行换码稍微有一些混乱。您可以使用 n ，不过我发现对 LF 的定义解决了这些问题。 在 show() 的文档字符串中定义的自测试所做的不仅是确保不发生异常（对照于最初的测试脚本）。为正确的“对象化（objectification）”至少要检查一个简单的 XML 文档。当然，仍然有可能

28、不能正确地处理一些其他的 XML 文档 - 例如，上面我们试过的名称空间 XML 文档 testns.xml 遇到了 EXPAT 解析器失败。由 doctest 处理的文档字符串 可能会在其内部包含回溯（traceback）,但是在特别的情况下，更好的方法是使用 unittest 。 回页首使用 unittest另一个包含在 gnosis.xml.objectify 中的测试是 test_expat.py 。创建这一测试的主要原因仅在于，使用 EXPAT 解析器的子软件包用户常常需要调用一个特别的设置函数来启用有名称空间的 XML 文档的处理（这个实际情况是演化来的而不是设计如此，并且以后可能

29、会改变）。老的测试会试图不借助设置去打印对象，如果发生异常则捕获之，然后如果需要的话借助设置再去打印（并给出一个关于所发生事情的消息）。 而如果使用 test_basic.py ， test_expat.py 工具让您可以分析 gnosis.xml.objectify 如何去描述一个新奇的 XML 文档。但是与以前一样，有很多我们可能想去验证的具体行为。 test_expat.py 的一个增强的、扩展的版本使用 unittest 来分析各种动作执行时发生的事情，包括持有特定条件或（近似）等式的断言，或出现期望的某些异常。看一看： 清单 4. 自诊断的 test_expat.py 脚本 Obje

30、ctify using Expat parser, namespace setup where neededimport unittest, sys, cStringIOfrom os.path import isfilefrom gnosis.xml.objectify import make_instance, config_nspace_sep, XML_ObjectifyBASIC, NS = test.xml,testns.xmlclass Prerequisite(unittest.TestCase): def testHaveLibrary(self): Import the gnosis.xml.objectify library import gnosis.xml.objectify def test