Question

尽管你可能不知道Robert是谁，但你很可能已经用过他写的程序，别的暂且不提，他是分布式版本管理系统Bazaar（http://bazaar.canonical.com/）的最初作者之一。目前，他是惠普云服务的“杰出技术专家”，从事OpenStack相关的工作。Robert还开发过本书中介绍的很多Python工具，如fixtures、testscenarios、testrepository和python-subunit。

你会建议使用什么样的测试策略？什么情况下不进行代码测试是可以接受的？

我认为这是一个软件工程上的取舍问题—需要考虑问题被引入未经检测产品的可能性，组件中未发现的问题产生的成本，从事这一工作的团队的规模和凝聚力……以OpenStack（http://openstack.org）为例，它拥有超过1600名贡献者，因此很难有细致入微的策略，因为很多人会有不同的意见。总体上来讲，应该有一些自动检查的方式作为代码并入主干时的组成部分，保证代码实现的正是其要做的，以及代码要做的也正是需要其完成的。通常来说，功能测试可能会放在不同的代码库中。单元测试的执行速度非常快，而且可以用来定义比较生僻的测试用例。我认为在已经有了测试的情况下，在测试的不同风格之间稍做平衡是完全可以的。

尽管测试的成本很高而回报较低，同时我也觉得在知情的情况下不测试是可以接受的，但这只是相对较少的情况。大部分事情都可以进行低成本的测试，而在早期发现问题的回报都相当高。

在编写Python代码时，有哪些令测试更容易且可提高代码质量的切实可行的最佳策略？

分而治之—不要在一个地方做多件事情。这便于重用，也可以让测试的重复运行更容易。尽可能使方法的功能单一，例如，对于单个方法要么用来计算，要么改变状态，但不要两者都做。这样就可以测试所有的计算行为而无须处理状态改变之类的操作，如写入数据库、与HTTP服务器交互等。相关的其他方式也同样受益，可以通过替换测试计算逻辑来触发生僻的测试用例的行为，并且通过仿真/测试进一步确认期望的状态传播是否如预期那样发生。测试IME最恶心的是深层栈，它们具有复杂的跨层的行为依赖。这里就需要不断改进代码，以使层之间的关系保持简单、可预测且对测试最有用的—可替换。

依你看来，在源代码中组织单元测试的最佳方式是什么？

使用类似$ROOT/$PACKAGE/tests的层次结构，但我对于整个源代码树只创建一个（相对于这种$ROOT/$PACKAGE/$SUBPACKAGE/tests）。

在测试文件夹内部，我经常镜像源代码的其余部分的结构，如$ROOT/$PACKAGE/foo.py将会在$ROOT/$PACKAGE/tests/test_foo.py中被测试。

应该避免从源代码树的其余部分导入测试包，除非是在顶层的__init__中放一个test_suite/load_tests函数。这样可以在小规模安装时很容易将测试分离。

Python中有哪些库可以用来做功能测试？

我只是用项目中使用的unittest的某些部分，它能灵活地满足大部分需求，尤其是同testresources和并行运行的其他方式结合。

你能展望一下未来Python中单元测试库和框架的发展吗？

我能看到的一些大的挑战包括以下几个。

· 在新机器上持续扩展平行处理的能力。要知道现在手机都有4个CPU了，而已有的单元测试内部API并没有针对并行的工作负载进行过优化。我在开发的StreamResult就是针对这一问题的。

· 更加复杂的调度支持—针对此问题的一个不太难看的方案就是对类和模块的作用域进行限定。

· 找出方法汇总目前我们拥有的大量测试框架：生成跨多个项目的汇总视图将非常有用，例如，对于集成测试，常常有多个不同的测试运行器在使用。