好的设计习惯可以拯救你的系统和头脑清醒
每个人都知道单元测试很重要，应该努力去测试所写的每一块代码。提倡以测试为驱动的开发者们甚至认为你应当先写下测试用例，然后用他们作为一个设计工具。不幸的是，对大部分团队和系统来说，真实世界粗鲁的打断和自动化测试覆盖面远远不够全面（包括单元测试，集成测试和完整的系统测试）。造成这种明显忽略良好习惯的原因多种多样。对测试爱好者来说令人震惊而且痛苦的真相是成功的复杂系统可以不需要充足的自动化测试就可以开发。成本可能更高，需要更多手工测试。但是，它是可能的。甚至那些大多数以测试为驱动的开发团队也会同意她们的代码是经过测试的（除了那些可能在一些生命攸关和任务攸关的行业）。在这篇文章中，我会一一详述并且展示怎样给传统意义上比较难测的代码块写测试用例。 就像你将会看到的，测试复杂系统与系统架构和你代码的设计有很大关系。这对软件系统的其它方面也是适用的，比如系统的可扩展性，性能和安全性。你不能在一堆恐怖的乱七八糟的代码上将他们吞咽。你必须从开端就设计它的可测试性或者重构的方法。好消息是好的设计（模块化和松散的连接起来的元素有良好设计性能和模块间的接口）可以形成一个系统，让它具有更好的可测试性，可扩展性，预先格式化和安全性。
基本知识
开发复杂的软件常常需要融合多个团队-可能不是在同一个地点或者不在同一个时区。你必须有一个很扎实的开发流程，它可以融合源头控制，一个自动化创建/配置的系统和自动化测试。这样一个环境的一个主要担心是怎样避免打破创建，因为有一个开发人员引起的破坏性的创建可以阻止到每个其它的开发者。一个破坏性的开发包括代码没有像预测中的那样表现。
比如，如果我引进一个缺陷到数据访问层，试图访问数据的每个代码块都会失败。系统越复杂，就越难修改这种特殊变化带来的影响（而这个可以通过好的设计来最小化）。自动化测试在这里就变得很关键了。如果所有的测试在你做出改变后通过了，你就能很确信说你没有破坏任何其它人的代码（假设是合理的测试覆盖范围）。
……………………
第三方代码
在一个复杂系统里，你的团队可能只要写一部分代码。你可能使用开源的库，从外部服务提供商获得的经过许可的代码，（更多时候是）从其它团队拿过来的代码。从经验之谈上来说，你不应当给不是自己写的代码创建测试用例。你通常通过一个API来使用第三方代码。在某些情况下，你直接就在代码中使用API。当在这种模式下操作时，第三方就等同于将库内建于你的编程语言或者操作系统中。然而，原始的API访问常常并不是最好的办法。API可能是很复杂的，它可能在各个版本间不稳定，也可能太地基，可能是一个C语言写成的API而你的系统是在C++环境中运行的。在这所有的情形下，团队人员可以选择去写一个包裹层在第三方代码上，这样可以暴露需要的功能，然后使用包裹层。这些包裹层对测试来说会很方便，因为（如果设计合理）他们很容易模仿。
