作者｜TimBray
翻译｜王强
审校｜燕珊
策划｜Tina
XML之父TimBray在日前发表的一篇博文中，基于自身的多年软件开发经验，分享了关于软件测试的那些事。“我非常确信，在我有生之年，对软件发展的最大贡献不是来自面向对象方法和高级语言、函数式编程、强类型、MVC或其他任何东西，而是来自测试文化的兴起。”
成熟的软件开发人员非常清楚测试的重要性。但是从我的经验来看，很多人在这方面做得还不够。所以我写下这篇文章的目的是要警醒行业，或许这对于我们的从业人员来说本是多此一举，但现实显然不是这样。
本文的灵感来自于JustinSearls的两个Twitter帖子，这里引据其中的几句话：“你听到的几乎所有关于软件测试的建议都是糟糕的。这些建议要么看上去就很糟糕，要么会导致糟糕的结果，要么会让你专注于错误的事情（通常是工具），结果分散了注意力”，“几乎没有团队会编写富有表现力的测试、建立清晰的界限、快速可靠地运行，并且只会因有用的原因失败。大家的重点都错了。”（注意：Justin显然身处测试行业。）
Twitter帖子都弯弯绕绕、很难摸清脉络，所以我从中贴两张截图出来。
我先亮明我的观点：我认为这些不规则的所谓的“结构图”是大错特错，而且影响严重。
背景
自年以来，我一直从事软件开发工作。虽然我的观点很可能是错的，但这并不是因为我缺乏经验。我做过的几乎所有有意义的工作都是底层基础设施的东西：解析器、消息路由器、数据可视化框架、网络爬虫、全文搜索。所以如果你不在基础设施领域，我的一些发现可能就不那么有说服力了。
在我编程生涯的前20年，比如说直到年，行业内几乎没有软件测试的位置。一个后果是，如同GeraldWeinberg经常被引用的一句话：“如果建筑师按照程序员编写程序的方式建造建筑物，那么飞来的第一只啄木鸟就会摧毁整个文明。”
那时，对于自己写的任何软件，我总会在几年后开始讨厌它，因为它变得越来越脆弱和可怕。现在回头想想，我抗拒的大概是那些未经测试的代码给人带来的体验，因为经常会有一些小更改由于难以理解的原因意外而引发“大灾难”。
至年的某个时候，情况开始发生变化。我的看法是，最初的推动力或多或少来自Ruby社区，并随着Rails的兴起而加速。我开始听到“测试的感染”（test-infected）这个词，我注意到如果提交的代码没有像样的单元测试，它们很容易被无情拒绝。
其他人告诉我，他们最初被围绕MartinFowler的《重构》一书中的讨论打动，这本书最早出版于年，告诉大家你无法真正重构未经测试的代码。
特别是我记得自己在年参加了苏格兰Ruby技术大会，会上似乎有一半的演讲是关于测试最佳实践和技术的。我在那里学到了很多我今天仍在应用的知识。
我非常确信，在我有生之年，对软件发展的最大贡献不是来自面向对象方法和高级语言、函数式编程、强类型、MVC或其他任何东西，而是来自测试文化的兴起。
我的信念
我们现在做事的方式好得多了。用回前面建筑师和程序员的比喻来说，文明不用再害怕啄木鸟了。
例如：我在谷歌和AWS工作的那些年里，我们遇到过很多中断和故障，但很少是因为某个软件错误这样简单的原因造成的。拙劣的部署、造成障碍的错误配置、证书问题（真是让人头疼）、DNS小问题、实习生使用Python脚本做负载测试、金丝雀故障……痛苦的记忆来自很多因素，但往往不会仅因为一个小错误。
我不记得我是什么时候被“感染”的，但我可以保证，一旦你被感染，你永远不会容忍未经测试的代码了。
是的，你可以在上过公共厕所后不洗手；是的，你可以用手指吃意大利面，但负责任的成年人不会做这些事情，他们也不会交付未经测试的代码。顺便说一句，我后来也不再讨厌我开发了一段时间的软件了。
随着时间的流逝，我对糟糕测试的容忍度越来越低。我阻止别人升职、给别人打低分、斥责高级开发经理，而且一般都没得商量。我可以不树敌，可以容忍（大多数）情况，因为我尊重他人、待人友善和富有同情心。但在这个问题上我不会后退。
所以，我至死都会坚持这项原则（呃，我想应该是一系列原则）：
单元测试是对软件未来的一项必不可少的投资。
测试覆盖率数据很有用，你应该密切
