在近期的一个大型项目中，我们在初期就制定了目标,我们不想让很多的QA人员手动测试我们的软件。通过手工测试来发现漏洞是非常耗时的，成本也很昂贵, 尝试尽可能从软件内部着手构建高质量的产品。这并不是说,手工测试应经无用武之地, 手动测试常常能触发某些你无法预期到的软件使用行为。
这是一个18个月左右的长期项目, 后续还会有持续更新。先前我们就发现,一个好的测试策略对项目的成功是至关重要的,特别是让我们的团队能够：1）随着时间的推移持续提高我们的效率,2)有信心应对我们的应用程序的大大小小的变更。
为了建立一个有效的策略，我们花了相当长一段时间。这主要是因为我们不得不学习如何在应用程序的每一层来设计我们的应用程序的可测试性。我们的团队成员之前都有很丰富的TDD经验,但这并不是我们需要创建一个有效的测试策略的唯一技能。
测试的层次
*系统测试
*皮下测试
*单元测试
皮下测试工作直接针对用户界面以下的内容。在一个web应用程序的环境中, 我们的我们用例的其中一个皮下测试是在所有的真实的类和实现都部署到位的前提下，通过命令行处理器发送的表单对象。我们绕过仅仅包含界面逻辑的控制层,直接到领域层。发送表单对象后,就能获取成功/失败的测试结果。
最后,我们有单元测试。单元测试的目的是测试一个类,可以是快或慢的测试。快速测试是正常的TDD测试,用于构建类的设计。根据需要进行重复测试,但严格interaction-based测试没有多大价值,除非我们找到非常有趣的交互。我们也有缓慢的单元测试,也可以归类为集成测试。这些将是诸如库测试、持久性测试,等等。
不同类型测试的比例，单元测试:皮下测试:系统测试在10:2:1附近徘徊。我们完成的这个项目大约有5000个单元测试，1000个皮下的测试中和500完整系统测试,使用WatiN和Gallio来驱动一个浏览器。这6000个单元/皮下测试大约10分钟执行完毕,然而500个UI测试需要大约50分钟完成。
单元测试策略
单元测试是在一个相当严格的TDD方式。在任何设备投入使用之前，我们都会编写测试，并使用测试驱动代码的设计。这些测试帮助识别设计问题,封装问题,代码问题等等。
我们努力避免编写纯粹用于提供测试的代码。它们常常意味着我们有设计问题、责任错位或封装已被破坏。
当我们进一步深入到项目管道,我们开始越来越少使用交互测试。也仅仅是满足对此真正感兴趣的人的兴趣而已。但更多的时候,我们更感兴趣的是它的副作用,而交互是一个实现细节而已。我们经常所做的反而是模拟缓慢或不可测试,如存储库,在外部服务facade,配置等。否则,我们模拟仅限于我们很感兴趣观察点。在大型项目中,它可以变得很明显,你的设计需要一个large-level重构,提取其中的概念使其更快实现交付功能。在我们最后的项目,一些概念发现包括:
§ AutoMapper
§ 处理的形式作为单独的命令消息
§ Input builders
有了所有这些，单元测试实际上是重构的一个保障。但只有我们依赖这些测试来覆盖应用程序中所有有趣的行为时，才能起到保障的作用。为了有效地允许大型和中型的重构，我们需要额外的测试级别。
