使用测试设备
因为我们通常会编写大量测试代码，并进行大量测试，我们要让自己的生活容易一点，为项目开发标准的测试设备（testing harness）。前一节给出的main函数是非常简单的测试装备，与之相比，我们通常需要更多的功能。
测试装备可以处理一些常用操作，比如记录状态，分析输出是否符合预期的结果，以及选择和运行测试，装备可以由GUI驱动，可以用项目的其他部分所用的语言编写，也可以实现为makefile或Perl脚本的组合。
在面向对象语言和环境中，你可以创建一个提供这些常用操作的基类。各个测试可以对其进行继承，并增加专用的测试代码。你可以使用Java中的标准名称约定和反射，动态的创建测试列表。这一技术是遵循DRY原则的好方法——你无需维护可用测试的列表。但是你出发前编写自己的装备前，你可以研究一下Kent Beck和Erich Gamma的xUnit。他们已经完成了这项艰苦的工作。
不管你决定采用的技术是什么，测试装备都应该具有以下功能：
●用以指定设置与清理（setup and cleanup）的标准途径。
●用以选择个别或所有可用测试的方法。
●分析输出是否是预期（或意外）结果的手段。
●标准化的故障报告形式。
测试应该是可以组合的，也就是说，测试可以由子组件的子测试组合到任意深度。通过这一特性，我们可以使用同样的工具，同样轻松地测试系统的选定部分或整个系统。
构建测试窗口
即使是最好的测试集也不大可能找出所有的bug；工作环境的潮湿、温暖的状况似乎能把它们从木制品中带出来。
这就意味着，一旦某个软件部署之后，你常常需要对其进行测试——在现实世界的数据正流过它的血脉时。与电路板或芯片不同，在软件中我们没有测试管脚（test pin），但我们可以提供模块的内部状态的各种视图，而又不使用调试器（在产品应用中这可能不方便，或是不可能）。
含有跟踪消息的 日志文件就是这样一种机制。日志消息的格式应该正规、一致，你也许想要自动解析它们，以推断程序所用的处理时间或逻辑路径。格式糟糕或不一致的诊断信息就像是一堆“呕吐物”——它们既难以阅读，也无法解析。
了解运行中的代码内部状况的另一种机制是“ 热键”序列。按下特定的键组合，就会弹出一个诊断控制窗口，显示状态消息等信息。你通常不会想把这样的热键透露给最终用户，但这对于客户服务人员却非常方便。
对于更大、更复杂的服务器代码，提供其操作的内部视图的一种漂亮技术是使用 内建的web服务器，任何人都可以让Web浏览器指向应用的HTTP端口（通常使用的是非标准端口号，比如8080），并看到内部状态、日志条目、甚至可能是某种调试控制面板，这听起来也许难以实现，其实并非如此。你可以找到各种现代语言编写，可自由获取、可嵌入的HTTP Web服务器。
测试文化
你编写的所有软件都将进行测试——如果不是由你和你们团队测试，那就要由最终用户测试——所以你最好计划好对其进行彻底的测试，一点预先的准备可以大大降低维护费用、减少客户服务电话。
尽管有着黑客的名称，Perl社区对单元测试和回归测试非常认真，Perl的标准模块安装过程支持回归测试（%make test）。在这方面Perl自身并无任何神奇之处，Perl使得比较和分析测试结果都变得更为容易，以确保顺应性（compliance）——测试被放在指定的地方，并且有着某种预期的输出。测试是技术，但更是文化；不管所用语言是什么，我们都可以让这样的测试文化慢慢渗入项目中。
