编辑推荐

　　《优质代码：软件测试的原则、实践与模式》专门从软件开发人员和技术人员关注的代码质量的角度来讲软件测试的原理、实践和模式。作者有30多年的软件开发经验，20多年软件测试技术的教授经验。书中积累了来自大量高水准软件工程师的多年经验。无论你是在写一个新系统，还是试图驾驭一个遗留系统，《优质代码：软件测试的原则、实践与模式》都会让你高效地开发高质量的代码。
　　测试驱动、测试先行和尽早测试这些开发实践，正在帮助成千上万的软件开发组织改善其软件。在《优质代码：软件测试的原则、实践与模式》中，作者立足于所有读者已经熟知的测试驱动开发知识，帮助读者实现亘古未有的优质代码。
　　为了帮助读者更加全面、有效和轻松地测试任何软件系统，《优质代码：软件测试的原则、实践与模式》使用真实的代码示例介绍了测试的模式、原则和20多个技术细节，并通过两个完整的案例分析，即测试一个全新的Java应用程序和一个未被测试的“遗留”JavaScriptjQuery插件，将《优质代码：软件测试的原则、实践与模式》讲述的所有内容整合在了一起。此外，作者还展示了一个概念框架，帮助读者将精力重点放在改善贯穿整个软件生命周期的可测试性上，并给读者提供了简化代码构造的全系列测试的实操指南。
　　无论是常见的场景还是多线程，《优质代码：软件测试的原则、实践与模式》都会帮读者学会如何针对每一种情景选择好的测试技术；无论是为一个新的创业公司开发前沿代码，还是维护一个很难驾驭的老旧系统，《优质代码：软件测试的原则、实践与模式》都会帮读者交付其真正需要的优质代码。
　　简化所有代码的单元测试，并改善集成测试和系统测试。
　　详述意图和实现，促进更加可靠和可扩展的测试。
　　克服对编写测试的机制的混淆和误解。
　　测试“副作用”、行为特征和上下文约束。
　　了解软件设计与可测试性之间微妙的交互，并对其进行利用，而非受困其中。
　　揭示能够指导关键测试决策的一些核心原则。
　　探讨以下内容的测试：getter/setter、字符串处理、封装、覆写变化、可见性、单例模式、错误条件等。
　　确定性地重现并测试一些复杂的竞态条件。

内容简介

　　　　《优质代码：软件测试的原则、实践与模式》讲述如何对所有的软件进行轻松的例行测试，书中为读者提供一些工具——一些实现模式，这些工具几乎可以测试任何代码。　　《优质代码：软件测试的原则、实践与模式》分为三个部分：第一部分（第1～5章）讨论了测试的一些原则和实践，包括首次优质、代码意图、测试攻略和测试与设计之间的关系等；第二部分（第6～13章）讨论了有关测试实践方面的一些模式，包括测试构造器和getter/setter、处理字符串、封装与覆写、调整代码可见性、测试单例模式、验证错误条件，以及利用各种接缝和测试多线程等；第三部分（第14~15章）展示了两个实例的编程过程，其中一个是用测试驱动开发方法编写新的Java应用程序WebRetriever，另一个是为一个未写测试的JavaScript开源项目jQueryTimepickerAddon添加测试代码。　　《优质代码：软件测试的原则、实践与模式》适合对测试驱动开发有初步了解或实践并想提升测试代码编写技能的程序员和自动化测试工程师阅读，也适合想通过《优质代码：软件测试的原则、实践与模式》在GitHub上的微量提交的代码来学习用测试驱动开发方法编写Java新项目和用测试来驯服JavaScript遗留代码的详细过程的任何读者阅读。

作者简介

　　StephenVance，从1992年开始，就已经成为专业的软件开发者、咨询师、经理、导师和讲师，从1997年开始，实践和讲授代码级别的自动化测试技术。他曾工作过的公司小到创业公司，大到财富100强企业，行业涉及广泛。他的演讲遍布美国和欧洲的软件技术大会。

目录

第一部分测试的原则和实践第1章工程、匠艺和首次优质1．1工程与匠艺1．2匠艺在首次优质中的作用1．3支持软件匠艺的实践测试1．4在代码检查器的约束下进行单元测试1．5针对覆盖率的单元测试第2章代码的意图2．1意图都被放到哪里去了？2．2将意图与实现分离2．3一个能引发思考的简单例子第3章从哪里开始3．1一种测试的方法3．1．1了解范围3．1．2测试的概念框架3．1．3状态和行为测试3．1．4测试还是不测试3．2攻略3．2．1测试"正常路径"3．2．2测试替代路径3．2．3测试错误路径3．2．4测试数据的排列组合3．2．5对缺陷进行测试第4章设计和可测试性4．1关于设计范型4．2封装和可观察性4．2．1表示性的封装4．2．2行为的封装4．2．3测试的灰度4．2．4封装、可观察性和可测试性4．3耦合和可测性第5章测试的原则5．1把测试雕琢好5．1．1将输入关联到输出5．1．2使用命名约定5．2避免在生产代码内出现测试代码5．3通过实现来验证意图5．4将耦合最小化5．5要最小的、新的和瞬态fixture5．6利用现有设施5．7要完整的验证而不要部分的验证5．8编写小测试5．9分离关注点5．10使用唯一值5．11保持简单：删除代码5．12不要测试框架不要测试生成的代码5．13有时测试框架
第二部分测试与可测试性模式第6章基础知识6．1bootstrapping构造器6．2测试简单的getter和setter6．3共享常量6．4在局部重新定义6．5暂时替换6．6封装和覆写6．7调整可见性6．8通过注入的验证第7章字符串处理7．1通过包含关系来验证7．2通过模式来验证7．3通过值来精确验证7．4使用格式化的结果来精确验证第8章封装和覆写变化8．1数据注入8．2封装循环条件8．3错误注入8．4替换协作者8．5使用现有的操作类第9章调整可见性9．1用包来包装测试9．2将其分解9．3更改访问级别9．4仅用于测试的接口9．5命名那些尚未命名的9．6变为friend9．7通过反射来强制访问9．8声明范围变更第10章间奏：重温意图10．1测试单例模式10．2单例的意图10．3测试的策略10．3．1测试单例的性质10．3．2对类的目的进行测试10．4独具慧眼的意图第11章错误条件验证11．1检查返回值11．2验证异常类型11．3验证异常消息11．4验证异常有效载荷11．5验证异常实例11．6有关异常设计的思考第12章利用现有接缝12．1直接调用12．1．1接口12．1．2实现12．2依赖注入12．3回调、观察者、监听者和通告者12．4注册表12．5工厂12．6日志记录与最后一手的其他设施第13章并行性13．1线程和竞态条件的简介13．1．1一些历史13．1．2竞态条件13．1．3死锁13．2一个用于重现竞态条件的策略13．3直接测试线程的任务13．4通过常见锁来进行同步13．5通过注入来同步例子：通过日志记录来注入同步13．6使用监督控制13．7统计性的验证13．8调试器API
第三部分实例第14章测试驱动的Java14．1bootstrapping14．2首要功能14．3切断网络连接14．4转移到处理多个网站的情况14．5幽灵协议14．5．1死胡同14．5．2spy手艺14．6执行选项14．7走向下游14．8回顾第15章遗留的JavaScript代码15．1准备开始15．2DOM的统治15．3在牙膏与测试之上15．4向上扩展15．5软件考古学15．6回顾封底文字

精彩书摘

　　当在软件领域出现了这种复兴运动后，其结果就是我们往往会淡化手艺（craR）、工程和创作之间的界限。另外，在软件开发中，还要去参与了解问题领域（problemdomain）的内容，这就难怪会在工作中把所应关注的问题与其他问题纠缠在一起了。但讨论这些的用意何在呢？　　专业的软件从业者，会在多个层次上进行编码、设计、架构、测试、度量和分析。这其中的一些内容，很明显就是工程。进行设计和由他人进行验证也很显然就是工程。但不管怎样切分，编码的行为，就是匠艺的行为，就是做出来的行为。当我们的手指在键盘上敲击的同时，我们或许是在并发地做一些“工程”，但这还是在做一门手艺。　　1．2匠艺在首次优质中的作用　　匠艺蕴含着技巧。在编码中所使用的技巧，决定着编码的结果。无论对软件做了多少架构、设计或构思的工作，一个差劲的实现就能够破坏掉所有这一切。　　作为传统，我们过去会依赖这样的验证，即通过自己的注意力或一个质量保证小组来手工确保软件行为的正确性。一位开发人员曾对笔者说：“我先编写代码，然后再训练它做正确的事情。”虽然他那种最终实现正确性的用意值得称颂，但是此话也表露出他对最初就把产品做好缺乏意愿和关注。当他花了l周时间在一个复杂系统中修改了一些核心代码后，令人哭笑不得的事情发生了，他又要求花3周时间来测试修改的结果。　　精益制造是运作在将优质构建到产品中的原则之下的。返工是一种形式的浪费，需要从系统中消除。j而先编写软件以待将来发现bug时再重写或修补，就是返工。　　测试那种本应正确的软件，就可以被看作是一种浪费。由于尚未找到创建没有缺陷的软件的方法，所以在编程之后进行测试在一定程度上是必需的。然而，当软件缺陷被发现、修复和重测时，对该软件所做的多于一次的测试显然是低效的。　　另一种形式的浪费是库存，可以将其视为机会成本。在修复bug上所花费的时间，也正是该软件中那些被正确编写的部分无法交付给客户或提供商业价值的时间。这个时间同时也是开发人员原本可以做包括职业发展在内的其他有价值的行为的时问。　　提升工作中的匠艺水平，能为个人和公司带来成倍的回报。它能令人用更少的时间和更少的浪费，来交付更多的价值，并带来更多的个人满足感。　　关于方法的一点看法　　首先需要事先声明，笔者是软件开发中敏捷和精益方法的热衷者。然而，笔者也坚信，世界上不存在一个或一组方法，能够适合每个团队、公司、项目或产品的情况。笔者从事过同时使用敏捷和瀑布开发方法的相当标准的软件项目，也把敏捷开发过程嵌入到瀑布式开发过程中，甚至在很大程度上，把敏捷技术运用到涉及实时控制和有关人身安全的产品上，还曾经雄心勃勃地以整个组织转型为目标，把敏捷和精益方法运用到前沿的Web开发上。　　无论使用哪种方法，项目中可能都已经有了某种形式的自动化测试，哪怕就是为了省却自己去按下按钮的麻烦。而更有可能的是，为了频繁地运行单元测试、集成测试、系统测试、组件测试、功能测试和其他形式的测试，项目已经拥有了某种形式的持续集成系统。　　只要有测试自动化的地方，就会有人编写代码来测试其他的代码。对于这种情况，《优质代码：软件测试的原则、实践与模式》所讨论的技术将会很有用。对于单元测试或隔离测试（iso1ationtesting），《优质代码：软件测试的原则、实践与模式》所讨论的几乎所有技术都适用。而对于更大范围的测试，或许可以选择来运用的技术就会少很多。一些技术只适合于某些编程语言，而其他技术则可被用于几乎任何编程语言或编程范型（progl‘ammingparadigm）。　　笔者会提及一些敏捷软件开发中常见的测试方法。即使有些方法不合某些人的开发口味，也不要让这一点成为去尝试它们的拦路虎。无论是实践测试驱动开发、测试先行、尽早测试或者测试后行（testafter），都仍然需要驯服被测代码。祝读者有一个快乐的测试！　　……

其他推荐