【作者序】
杰夫·朗格尔（Jeff Langr）的序
10年前，我曾在当地一个小创业公司就职，经过几个月的开发工作，我成了这个开发团队的经理和技术主管（technical lead）。当时团队写的代码几乎充斥着各种典型的费解的逻辑和难以解决的缺陷。作为团队的领头人，我开始推广测试驱动开发（test-driven development，TDD）的理念来尝试提升我们代码的质量。最终，大部分开发者都愿意听从这个建议，也有几个开发者最终欣然接受了TDD。
然而，有一位开发人员仅过了两天就一声不吭地退出了团队。有人告诉我，他说过类似"我永远不会去写测试，那不是一个开发人员要做的事情"的话。我一开始担心是不是我对这件事操之过急了（虽然我从来没有执意要求什么，只是尝试着让他们了解TDD），但是，当我看到了他写的如同噩梦般的代码后，我就不再觉得愧疚了。
之后有一位测试人员向我抱怨：团队中有个开发人员--拥有多年经验的顾问-- 一直在提交充满缺陷的代码给我们的测试团队，并称"写代码是我的工作，找出代码问题是他们的工作"。即使再多的商讨也无法说服这位先生能够测试他自己的代码。
后来，还是在这套代码上，我发布了一个带有严重缺陷的版本，尽管我尽了各种努力去确保所有单元是被很好测试过的，这个缺陷还是没有被测试团队发现。对服务器代码的一点点修改和对一个布尔变量的轻易改动导致了客户端（一个高安全聊天应用）不再对新消息进行铃声提示。当时，如果我们做了全面的端到端测试（end-to-end testing）就能发现这个缺陷。
开发者测试只是一种手段，但不是为了让你的老板高兴而已。如果它仅仅是这样的话，那我宁愿不去创建开发者测试。无论是将软件发布给最终用户还是发布给测试团队，测试都是建立自信的一种手段。
值得庆幸的是，10年过去了，大部分的开发者都能意识到"测试自己的代码确实是开发工作的一部分"。在面试中，很少有人会遇到不讨论任何有关开发者测试的情况。我们都期望成为一名非常专业的软件开发人员，而写出高质量的代码是不可或缺的。10年后的今天，如果应聘者认为他们不需要对自己的代码做测试，我就会打消聘用他们的念头。
然而，开发者测试不仅仅是TDD，也不再是简单地写一些集成测试。为了交付正确且高质量的软件，一个真正的开发人员必须要接受很多方面的测试。尽管你可以找到介绍TDD或者组合测试的好书，但《程序开发人员测试指南：构建高质量的软件》（以下简称《开发者测试》）则涵盖了这两个方面的必要内容。为了阐明各式各样的开发者测试，作者（亚历山大）纵览了测试的世界，权衡各种测试方法之间的优势，为你提供了成功路上不可或缺的诀窍。
在本书中，亚历山大首先展示了那些需要关注的测试。他介绍了一些被人们忽视但很实用的观念，例如契约式编程（Programming By Contract）。他教会我们如何设计出容易被测试的代码。他强调了两个我喜欢的目标：
· 构建具有高可读性的、基于规格说明的测试，依旧保持文档的价值；
· 消灭高质量系统的最大敌人之一--各种坏味道的复制。
他通过实用的、平衡的方法做好TDD，并呈现了传统的TDD和Mockist TDD的应用技巧，从而向我们全面介绍了单元测试的内容。
等等，我还要再说说第18章："超越单元测试"。开发者测试是一个模糊不清的世界，这一章对单元测试之外的内容讨论之广超越了我们的期待。设计稳定、有效、可持续发展的测试是一个挑战。本书提供了丰富的、独特的智慧来处理这个问题，一定不会让你失望。
我享受经历本书完成的过程，随着亚历山大完成内容丰富的代码部分，我觉得书变得越来越棒了。想出让读者参与到书中并且感受不到挫折的例子是一件很难的事，但是亚历山大用他写的例子成功地做到了这点。我想你会喜欢这本书，并且庆幸在你事业的成长路上拥有关键的测试技巧的基础。
丽莎·克里斯平（Lisa Crispin）的序
本书的副标题昭示了一切。我们知道不能通过编程"结束"之后的测试来测试所构建的软件质量，软件质量必须被融入到编程过程中。因此，整个交付产品的团队，包括开发者，在开始构造功能时就要思考怎么测试它。在成功的团队中，团队的每个成员都拥有敏捷测试的思维。他们与客户、交付团队协作，试图理解什么才能帮助客户获得成功。相对于找到代码错误，他们更关注于如何避免错误。他们能够找到提供合适价值的最简单的方案。
在我的经验中，即使团队里已经有了经验丰富的专业测试工程师，也需要让开发人员懂得测试。开发人员要能够与设计师、产品专家、测试人员及其他的团队成员交流，每个功能都应该这么做；需要设计可测试的代码；要懂得如何从单元直到系统都能用测试来指导编码；要像懂得生产代码那样懂得如何设计测试代码，甚至更要了解，因为测试代码是我们活的文档，是我们的安全帽；要懂得怎样去探索他们开发的每一个功能，去了解这些功能是否带给客户相应的价值。
我遇到过许许多多这样的团队：开发者被雇用去写产品代码并不断被施加压力追赶一个又一个的最后期限。他们的经理认为将时间花在测试上是一种浪费。若这样的团队中有任何测试工程师，他们会被认为是团队中价值不高的贡献者，并且他们发现的bug只是记录在缺陷跟踪系统中，但往往被忽略。这些团队开发出大量的没人能看懂的代码，这些代码很难在不破坏其他功能的情况下进行修改。随着时间的推进，他们通常在技术债的重压之下慢慢停止下来。
多年来，我很幸运地能够和几位真正懂得测试的开发者们一起工作。他们积极与领域专家、设计师、测试工程师、大数据专家等人沟通，从而对于各种特性该如何表现能够达成共识。他们与测试工程师相处融洽，就算在代码提交到测试环境之前也会愉快地对自己的代码进行测试。这些团队是快乐的，能够开发可靠的、有价值的功能给用户，他们能够迅速改变方向来适应新的业务优先级。
测试是一个广阔的领域，而繁忙的我们应该从何下手？这本书通过一种让你迅速上手的方式传递了测试的重要原则和实践，帮助你及团队向用户交付他们真正需要的东西。你将会学到测试的语言，然后和测试工程师、客户及其他团队成员高效合作。更重要的是（至少对我来说），你将会更享受你的工作并且对你做的产品感到自豪。
【致 谢】
写书是一项团队工作。虽然作者是写下这些文字并与它们相处时间最多的人，但其实很多人都做出了贡献，这本书也不例外。首先我要感谢拥有独特视角的软件领域专家、我的好友乔金（Joakim Tengstrand）。在这本书的开始阶段到书的完成，他不断地提供了许多有深刻见解的反馈。
另一个我要特别感谢的人是Stephen Vance。他很热情，从技术角度来帮我对本书进行二次校对。他不仅提供了很有价值的反馈，还找到了很多（即使不是全部）我想要偷懒的地方。此外，他给了我一些更多选择和观点来帮我拓宽这本书的内容。
事实上，如果没有丽莎·克里斯平的帮助，这本书将不会以现在的形式出现。她帮我出版了这本书，整个过程中，在我需要帮助的任何时刻她都在支持我。我很荣幸她能为本书写序。谈及此，同样深深感谢为本书写另一序言的杰夫·朗格尔，他还激发了我重写已拖延了很久但重要的章节。我无法表达对Mike Cohn有多感激，虽然我从未有幸与他谋面，他却将我的书收入他的系列，这对我来说意义真的重大。
在这本书的出版方面，我真的要感谢艾迪生韦斯利出版社（Addison-Wesley）的克里斯（Chris Guzikowski）。他在整个过程中表现得非常专业，最重要的是他突破各种所限以支持本书的出版。我不知道我写了多少开头类似于"非常感谢您的耐心，但在我提交手稿之前我还有一件事要做……"的E-mail。在本书后期定稿过程中，我很荣幸能够和乐于助人的非常专业的人士一起工作，是他们让这段旅程变得有趣、富于挑战。在此非常感谢Chris Zahn、Lisa McCoy、Julie Nahil和Rachel Paul。
本书的审稿者--Mikael Brodd、Max Wenzin、Mats Henricson--为本书的第一遍技术校对做了巨大贡献。
特别感谢Carlos Ble带我参加了一个TDD活动，由此产生了一个和本书中有关TDD章节很不一样的解决方案。这件事引发了我的进一步思考，最终促进我重写了整个章节。Ben Kelly很好地帮助我弄清楚书中一些测试术语的细节，使我不得不区分开发人员和测试人员某些不同的工作。Dan North帮助我弄明白BDD和ATDD。Frank Appel在单元测试及其相关资料上帮助了我。他所做的评论不仅详尽，而且有根有据，有时候让我不得不停下来进行深刻的思考。对此，我感激不尽。Alex Moore-Niemi提供了关于类型的补充内容，拓宽了本书的范围，而我对此的理解是很肤浅的。
我同样要感谢Al Bogdonas，我的初稿校对员兼编辑对这个项目的奉献。
此外，我同样要感谢那些帮助过我或给我灵感的人：Per Lundholm, Kristoffer Skjutare, Bobby Singh Sanghera, Gojko Adzic, Peter Franzen。
最后，我要加入那些感谢妻子和家庭的作家队伍。写书需要热情、奉献、努力，最重要的是，需要牺牲家庭时间。Teresia，谢谢你的耐心和支持。
【作者介绍】
20世纪90年代初，10岁的亚历山大（Alexander Tarlinder ）写下了他的第一个程序--Commodore 64计算机上的简单的基于文字的角色扮演游戏。程序里面有很多的GOTO语句和大量重复冗余的代码。但对于当时的他来说，这仍然是他能够构想出的最棒的软件，也成为了他之后职业道路的起点。
25年过后，亚历山大仍然在写代码，内心还是把自己视为一位开发人员。15年的职业生涯中，他做过开发者、系统架构师、项目经理、测试工程师和敏捷开发专家及教练。在这些工作中，他保持可持续的开发节奏、匠人精神并关注质量，最终大约在2005年深受测试的影响。从某种程度上来说，这是不可避免的，因为他的项目很多代码都涉及了资金（比如为银行或者游戏行业做的产品），他总认为在将产品交给别人之前他可以做更多的事去保证代码的质量。
目前，亚历山大在寻找能让他对项目的实施过程有更大影响的角色。他将开发项目与培训、训练相结合，并在研讨会和一些当地用户见面会中分享他对开发者测试及质量保证的技术和非技术方面的理解。
51Testing软件测试网将在近期对本书部分章节进行独家连载，敬请关注
查看更多《51Testing软件测试网作品系列》：http://www.51testing.com/html/36/category-catid-136.html
