【译者序】
一年前，也是端午节，很巧合，本书的一个译者为另一个译者的新书《软件测试价值提升之路》写序。一年之后，还是端午节，我们一起为不一样风格的软件测试译著《程序开发人员测试指南：构建高质量的软件》（后简称《程序开发人员测试指南》）写序，依旧充满诗意，享受着成功的喜悦，并郑重推荐本书给所有的软件开发者。
回想当初，朱少民从人民邮电出版社接下这本书的翻译任务，邀请 3 位测试界朋友杨晓慧、欧阳辰、曾天乐组成翻译团队，开启了本书的翻译旅程。我们虽是测试老兵，但从接下任务之后，还是感到较大的压力，始终怀有一颗谦逊的心来做这项工作。一方面它是全球第一本以"开发人员测试"命名的专业图书，希望中译本能够得到大家的长久喜爱。另一方面，翻译不是一件很容易的事，比写书还难。写书可以按照自己的想法、意愿去写，翻译则是"戴着脚链在跳舞"，经常需要仔细地揣摩原作者的写作思路或所表达的具体含义。就拿我们所整理的一个术语表为例，其中收集了218个术语，几经修改，先后出了好几个版本。多数术语很容易统一起来，有些术语（如quirk、circular argument、code bloat等）会有争议，不容易达成一致，查证各种资料，最终才达成一致。甚至面对个别术语（如Mockist、Test Double、Stub），我们觉得多数开发人员更容易理解英文术语，没必要翻译成中文，但为了图书规范，尽量把各种术语翻译成中文，只是在其第一次出现时，注明原英文术语。
十年前或更早，许多优秀的软件公司都有独立的测试团队，更强调测试的独立性、客观性，开发的质量很大程度上依赖于独立测试的质量。那时，微软公司拥有大约一万名专业的测试人员（Software Development Engineer for Test，SDET），成为全球为数不多的测试大军团，因此，那个时代微软是许多公司的测试标杆，大家学习微软如何做测试，参加由微软资深人士开设的培训讲座。那个时候，我们曾经亲身经历的项目，开发人员所做的测试很少，更多的测试是由专业的测试团队完成。即使大家都认为"单元测试应该是由开发人员来做"，单元测试的覆盖率也非常低，其效果依旧不理想，可圈可点的项目很少。 不少项目推行过开发者测试，成功者寥寥，甚至个别项目想摆脱独立的测试团队就直接上线，结果也是铩羽而归。
然而，最近几年敏捷开发席卷而来，到处开花结果，所有开发者越来越关注质量，开始做越来越多的测试。微软测试军团从2010年开始瓦解，到2014年烟消云散，绝大多数的SDET快速融入开发团队之中，成为开发工程师的一员，而剩余的SDET要么改行，去干运维、技术支持等工作，要么辞职，去其他公司继续专职的测试工作。今天，Google、Facebook等公司成为新的标杆，人们开始推崇非常简单的工程师文化、推崇开发与测试的融合。在这样的环境下，开发人员不仅需要完成代码，还需要全力保证代码的质量，要求开发人员做足够的测试。但是，开发人员不是天生下来就会做测试，测试能力还比较弱，甚至有些开发人员在今天敏捷开发的环境下，依旧排斥测试，开发者测试在国内不容乐观，这里面有客观因素，也有主观因素，但无论如何需要改变。
如果按照过去那种瀑布模型做测试，先开发，后测试，开发人员会遇到心理上、思维上的障碍。而从理论上看，测试驱动开发（TDD）则彻底解决了这个问题，因为测试在前，开发在后。在开发前，测试的思维不会受到实现思维的影响；实现的代码还没有，自然也不存在心理上的障碍。理想很丰满，现实很骨感，TDD的应用还是凤毛麟角，因为TDD的具体实施会面对各种困难，如给开发人员带来额外的工作量、如何摆脱过去写代码的习惯等。例如，在TDD实施时，我们经常能够听到开发人员说，"再给我加一倍的时间"。由于增加较大的工作量，在进度压力下就很难实施TDD，或者说，许多团队不知如何实施TDD，如何更高效地完成软件的开发且提高质量，不仅让客户满意，而且也带来生产力。如果管理层有坚定的决心，并敢于在组织、流程、策略上做出相应的改变，TDD可以带来"质量"和"生产力"的双收益，不靠事后检验，可以大大降低质量劣化带来的成本。
开发者测试不仅仅局限在TDD、单元测试和集成测试，组件之间的交互性测试、调用系统进行更高层次的测试也会出现在开发者测试中，开发者测试也不仅仅使用测试技术，可测试性、依赖关系、复用和契约式编程、防御式编程等以构建高质量的代码为目的的技术也与开发者测试息息相关。测试不能真正保证质量，软件质量是在设计、编程过程中慢慢形成的。从这个角度看，开发者测试更为重要，在开始构造功能时就要思考怎么测试它，相对于找到代码错误，他们更关注于如何避免错误。在成功的团队中，团队的每个成员都拥有这样的理念：构建高质量的软件（正是本书的副标题）。他们与客户、交付团队协作，试图理解什么才能帮助客户获得成功，如何找到最有效、最简单的解决方案。这本书正是从这个角度展开讨论，以帮助开发人员正确地理解和掌握开发者测试，解决开发人员从准单元测试开始，到测试替身、模拟框架、不同的TDD模式等测试中遇到的各种障碍。本书还有其他一些特点，下面就让我们逐一介绍。
首先，这不是"测试专家写的开发者测试"，而是"开发专家写的开发者测试"。书中并没有花太多篇幅介绍测试的概念、测试设计技术、单元测试工具（这些可能是我们之前推行开发者测试的重点），而是把重心放在了可测试性、影响测试的编码风格、实现开发者测试的方式、测试环境和条件的构造、开发者测试在全部测试活动中的位置和作用等方面（这些是真正影响开发者测试效率的问题）。因此，这本书对于开发人员具有很好的实用价值。
其次，这本书不是一座"大山"，而是若干"甜点"组成，除了前3章介绍测试的基本概念和术语，其他各章相对独立，一章基本是一个主题，阐述开发者测试所遇到的问题、解决方法、注意事项等。即使隔了很长时间我们才读另一章，或者跳过没有兴趣的个别章节，也完全不影响我们阅读的体验或收获。"甜点"还隐藏在每一章中--每章穿插着一些"小窍门""经验之谈"或"注意事项"等，点拨读者，读者获得启发或警醒。
再者，本书实例丰富，循序渐进，例如14.1 节就用了"一个简单的搜索引擎"的8个实例，一步一步地介绍经典风格的TDD是如何实施的。本书的内容安排得当，有主有次，主次分明，例如许多测试书籍都有"基于需求的测试方法"的详细介绍，本书则用较少篇幅快速带过。而对于重点内容，如可测试性、Mock技术和TDD，分别用了两章阐述其不同的方面。在Mock技术中，逐一介绍了如何应用不同的Mock对象--桩对象、伪对象、模拟对象、监听器、哑对象，更体现其专业水准。
最后，这本书中的开发者测试不是"孤立"的，而是"在上下文中"的（上下文是软件工程中最重要的概念之一）。书中将开发人员与测试人员放在一个场景中，让读者更好地理解问题发生的前因后果。将问题放在代码中（很多还是来自于实际产品的代码），方便读者映射到自己的产品和代码中，并设想解决问题的方法是否适合自己，留给读者更大的思考空间。将测试活动放在实际的研发项目中，单元测试和模块集成、独立模块测试的区别并不那么明显，书中也不回避这些现实问题，而是帮助读者看到这些测试的真正过程，使读者可以根据项目的具体情况做出策略选择。
我们非常高兴参与本书的翻译，翻译过程虽然很辛苦，但也是快乐的学习过程，能解开我们对开发者测试的一些疑惑。唯一的遗憾是，相见恨晩矣！如果早几年读到此书，在之前的工作中，很多事情会有更好的方式做，比如TDD、单元测试，比如代码质量检测、敏捷一体化团队……相信本书对开发者们会有更大的帮助，会逐步提升开发者的测试能力。开发者测试做好了，在未来交付项目代码时，会感到很轻松，会更加充满自信。
译者
于2018年
51Testing软件测试网将在近期对本书部分章节进行独家连载，敬请关注~
更多《51Testing软件测试网作品系列》书籍：http://www.51testing.com/html/36/category-catid-136.html
