Testing Is the Engineering Rigor of Software Development
当开发者尝试向家人、配偶及非技术人员解释它们是做什么的时，喜欢用象征性比喻。我们经常（将其）诉诸为桥梁建造或者其它“硬核”工程学科。但是，当你试着把它们说得太难时，这些隐喻是经不住考验的。事实证明，软件开发在很多方面并不像那些“硬核”工程学科。
相对于这些“硬核”工程，软件开发的世界更像是桥梁建造者的地位，当时一个共通的策略就是先架起桥梁，然后在往上铺设一些很重的东西。如果它稳固，说明很好。如果不是，那就重新回到图纸层面。经过了数千年，工程师们创建了数学和物理学，将其运用于结构化的解决方案，而非先把它造好再看看效果。然而在软件开发中我们却没有任何可利用的东西，或许永远都不会有，因为现实中的软件开发太难了。为了深度探索比较软件“工程”与其它工程，Jack Reeves在1992年在《C++期刊》上发表了“什么事软件设计？”，很经典。尽管它写于20多年前，仍然非常精确。Reeves在对比中描绘了一幅悲观的画面，但1992年那会，强大的软件测试精神是缺失的。
测试“难”在你必须先构建它们才能对它们测试，这就阻碍了那种只想看看会发生什么的投机性构建。不过在软件中构建过程廉价得令人发指。我们已经开发了一套完整的生态系统工具以便于轻松做到：单元测试、模拟对象、测试用具，以及大量的其它东西。其他工程师们肯跟热衷于建造事物并在行之有效的条件下测试它。而作为开发者，我们拥抱测试，将其作为软件验证机制的主要手段（但并非唯一）。与其等待软件的某些排序计算，我们可以用工具进行处理，确保良好的工程实践。从这个角度看，我们现在有证据去抗议那些所谓的”我们没时间搞测试“的领导。一个桥梁建造师可能永远不会听到他的老板说一句：“不用做什么建造的结构分析了——我们期限快到了。”测试确实是可复用性和质量的途径，作为软件的开发者，可以将反对这种观点（的人）视为对专业的不负责任。
测试需要时间，正如结构分析也需要时间。都是为了保证最终产品的质量。是时候让软件开发者承担起他们对产品的责任了。独立测试是不够的，但它是必要的。测试是软件开发的工程严谨性。
