在本书中，敏捷方法专家James Grenning演示了为什么和如何在嵌入式软件开发中应用测试驱动的开发方法，他用详细的例子引领读者从TDD的基础走向精通。本书主要内容包括：第一部分介绍了两个开源的测试框架，通过测试驱动开发方法开发第一个模块；第二部分深入介绍了与系统中其他模块进行交互的代码的测试技术，如测试替身、仿制对象等；第三部分介绍了设计与持续改进代码，如写出更好代码的一些重要原则，建立可测并灵活设计的高级技术，改进已有代码的实践方法——重构技术，改进遗留代码，以及编写和维护测试的指导原则。本书的代码几乎全部用C写成，并且可以用于嵌入式的、受约束的开发和执行环境。
本书深入介绍了如何把测试驱动开发应用于嵌入式C语言开发，适合嵌入式C/ C++语言程序员、工程师阅读。
我想这本书将成为嵌入式软件工程师的“圣经”。
—Robert C. Martin
测试驱动开发（TDD）是C语言开发人员需要掌握的一种现代编程实践。它是一种不同于以往的编程方法——在一种紧致的反馈循环中写出单元测试与产品代码。你时刻都会得到有价值的反馈。你会在失误变成bug前就找到它们。你会有更多的时间花在为产品增加有价值的特性上。
James是为数不多的把测试驱动开发应用于嵌入式C的专家之一。他在培训以及实践用C、C++、Java和C#做测试驱动开发方面拥有15年的经验，可以引领你从TDD的入门走向精通。
我第一次接触测试驱动开发（Test-Driven Development，TDD）是在1999年的首次极限编程俱乐部活动里（Extreme Programming Immersion）。话说那时，我正在一个开发嵌入式通信系统的团队里工作。我从客户那里离开了一个星期去参加那个俱乐部活动，在那之前我们刚刚从项目的需求文档中提取出用例。这件事改变了我的职业生涯。我发现了测试驱动开发（以及其他事情）。
像很多嵌入式开发工程一样，产品的发布因为软件开发而受阻并不是什么新鲜事儿。但我们那时没有办法开始工作却是因为硬件和操作系统还没确定，或者说还没准备就绪。项目整体的进度因而一天天延期。我们一再被重新召集到一起，因为目标硬件这个瓶颈让进度像点滴一样缓慢。 除了开会、交谈、争论或者把我们想做的软件写成文档，我们还能做什么？事实是，还有很多事情可以做。
所有的嵌入式开发人员都经历过目标硬件瓶颈。通常硬件和软件是并行开发的，并且在开发过程的大部分时间里是不可用的。更糟的是，硬件和软件中都有bug，至于这些bug到底在哪里却是说不准的。还有这样的情况：目标硬件很昂贵，不可能做到开发人员人手一套目标系统等着他们来用。开发人员需要等待，等待也同样要开销。
在为期一个星期的极限编程俱乐部活动之后我终于领悟了！ 除了写文档和等待我们还有更多事可以做。实践上我们马上就可以行动起来。测试驱动开发是在硬件就绪之前以及整个开发过程中的关键。
在这领悟之后的岁月里，我学习并传授用C/C++、Java和C#来做TDD。同时，我还涉足了其他几种语言。我发现，我几乎是唯一一个在嵌入式开发领域为TDD呐喊的人。看来，我需要写一本书。
本书读者对象
尽管本书的标题中有“测试”字样，但是这本书并不是为软件测试人员而写的。本书是为你这样的嵌入式软件开发者写的。你从前可能以为TDD是别人的事。过去所有关于TDD的书使用的都是Java或是高端动态语言。相关的大会演讲和论文通常也是以网站开发或桌面应用开发为目标。那些关于TDD的东西所用的编程语言对你来讲都是外语，他们讲的都是外国的事情。而你所关心的东西却从来没被提及或考虑过。
本书的使命是带给你一些在过去十年里软件开发领域中精炼过的伟大思想。在本书中你会发现用你所熟悉的语言所写的代码示例。这些思想会给你带来挑战。他们会帮助你打造更好的软件并让你从漫长的“测试再修正”过程中解放出来。
尽管本书主要的目标读者是嵌入式C语言程序员，但是其他的C语言程序员也可以从本书中学到TDD的方法。本书的例子全部来自于嵌入式领域，但教授的东西不会有太大区别。我的C代码有浓郁的面向对象的风格，所以C++程序员也可以从本书中学到很多。
如何阅读本书
尽管你不必在通读本书之后才开始动手做TDD，但是本书的设计意图是希望你能从头到尾按顺序阅读。当你读过第一个完整的例子之后你就可以动手自己做了，第一个例子是LED（发光二极管）驱动程序。让我来介绍本书的三个部分。
在对TDD进行简单介绍之后，第一部分会讲到两个开源的测试框架。然后我们一个测试一个测试地来开发第一个模块。通常，开发人员刚一看到TDD就会有很多疑问。因此，与其让这个疑问萦绕在那里，我花了几章来回答我在过去十年里经常被问到的关于TDD以及在嵌入式开发中应用TDD的一些问题。
在本书的中间部分，我们会深入到需要与系统中其他模块进行交互的代码的测试技术中。我们将举出一些脱离依赖关系的例子。我将介绍一些“测试替身”（test double）和“仿制对象”（mock object）的概念。为了要做到彻底地测试驱动编码，它们都很重要。这部分将用工具把你武装起来，在更复杂的世界里开发交互模块时你会用到它们。
本书的最后部分有四个重要章节。首先，我们将看到可以帮助你写出更好代码的一些重要原则。我们将看到一些建立可测并灵活设计的高级技术。其次，我们进入“重构”部分，那是关于改进已有代码的实践方法。在这之后我们将看到在你的遗留代码中的一些问题，以及如何安全地用测试把它们保护起来，从而可以着手改进已有的这些你曾经为之付出过很多努力的代码。最后，我们总结了一些如何编写和维护测试的指导原则。
如果你对TDD已经很有经验，现在只是想要用测试来驱动开发C语言编程，你可以跳过本书的第一部分。（如果你发现我做TDD的方式和你所熟悉的方式不同，也许你最好再回头看看开头这部分。）对于有TDD经验而只是关心如何用TDD来做C的程序员，书中真正耐人寻味的东西在第二部分和第三部分。
如果你的水平更接近一个TDD初学者，请从本书的开头读起。边读边用书中例子来编码练习。按照每章后面“学以致用”一节的建议去做。在完成第一和第二部分后，你将掌握一套在项目中可用的不错的工具。
如果你相对来讲不大熟悉C语言，或者对C语言的一些部分还不熟，可能对你来讲阅读第11章会很有挑战。如果这对第一次来讲太难了，那么在用TDD来写C代码几个月后再来试试重新读一遍。
本书中的代码
本书中有大量的代码。没有它们你没办法了解TDD中的细节。和我一起阅读这些代码，这样才能从本书中得益最多。
关于如何在开发系统中建立一个测试环境，在附录A中你可以找到一些帮助。在代码下载目录中的code/README.txt中可以找到编译示例代码的指导。
随着本书内容的展开，代码也在演变。有些演进很小，旧版本还保留在 #if 0 … #endif这样的编译开关之间。有些则有非常大的演变，在有些章节中需要把代码移植到一个新的目录体系结构中。在更后面的章节中，你会注意到演变的 code/t0、code/t1、code/t2和code/t3目录。
很可能我用的编程规范和你的不同。不过我真的花了不少精力来表现出一致的编程风格。我用GCC，所以这些C代码在ANSI兼容的编译器中可以编译。
我在本书中采用了两种测试框架，Unity和CppUTest，二者都包含在本书的代码下载中。Unity是一个完全只用C的测试框架，在本书的开头部分会使用它。CppUTest是用C++来写的并同时以测试C和C++为目标的测试框架。现在，世界上有很多C程序员使用CppUTest。C++的部分隐藏在一些宏里。用CppUTest所写的测试看上去和Unity测试的一样。在转变之前我会解释为什么我在后面的例子中选择C++编译器。当你学习到更多关于TDD和测试框架的东西后，你将能自己来决定哪种测试框架对你的项目开发最适用。
感谢你拿起本书！希望这本书对你建立出色软件的热情有所帮助。
在线资源
这里有些你可能喜欢的在线资源：
本书的主页：http://www.pragprog.com/titles/jgade
得到本书的更新，讨论，勘误，以及下载本书的代码。
CppUTest.org：http://www.cpputest.org
找到关于CppUTeest的文档和讨论
SourceForge.org网站的CppUTest：http://www.cpputest.org
下载最新版本的CppUTest。
Unity：http://unity.sourceforge.net
Unity的主页。
作者的主页：http://www.jamesgrenning.com
在作者的博客中可以获得本书的最新信息、TDD以及嵌入式中的敏捷等。其中有其他相关资料的链接。
在本书中，敏捷方法专家James Grenning详细地演示了为什么和如何在嵌入式软件开发中应用测试驱动的开发方法。作为来自纯嵌入式开发领域的一员，我开始的时候并不看好TDD。但看过了手边的这本书，我已经准备投入其中，而且我确信甚至可以把TDD应用于设备驱动以及应对其他底层代码所面临的挑战。
—Michael Barr
《Programming Embedded Systems: With C and GNU Development
Tools and Embedded C Coding Standard》的作者， Netrino公司
“测试驱动开发在我们这里不适用！我们用C，但测试驱动开发要求用Java这样的面向对象语言！”在指导团队用C语言做TDD时，我常常听到这样的声明。我总是把它们引向James Grenning所做的工作，例如他写的文章“嵌入式的TDD循环”。James是在嵌入式产品开发中应用敏捷的领头人。当他告诉我他要写这本书时我非常兴奋，因为我觉得它一定会帮助嵌入式敏捷社区更进一步。James花了两年多的时间来写这本书，它真的值得期待。这是每个嵌入式开发者都应该读的一本好书。
—Bas Vodde
《Scaling Lean and Agile Development》及《Practices for Scaling
Lean and Agile Development》的作者，新加坡Odd-e公司
多年来，我一直宣扬和教授用C语言来做TDD开发，现在终于有一本书我可以推荐给那些想学习现代编程技术的C程序员了。
—Olve Maudal
思科公司C程序员
这是一本实用指南，它澄清了如何把敏捷开发实践应用于嵌入式软件开发的世界。很快你就可以写出测试帮助在早期就精确地指出问题所在，而不必苦苦地找寻到底是怎么了。从我在为机器人、遥测设备以及通信产品写代码的经验来讲，我衷心推荐阅读这本书。它是学习如何把测试驱动开发应用于嵌入式C语言开发的极好方式。
—Rachel Davies
《Agile Coaching》的作者，Agile Experience公司
这是一本让人期待很久的书。它指引读者走过将C语言应用于嵌入式软件的测试驱动开发所面临的独特挑战。它用示例代码解释了TDD用到的原则和技术，从开始到结束，开辟了一条清晰的路径。我把这本书推荐给任何在嵌入式开发领域有兴趣把事情做得更好的人。
—Timo Punkka
软件开发经理，Schneider Electric公司
这本书就是为街上能随便找到的嵌入式程序员而写，而且它做到了。它既不是像对婴儿用勺子喂饭时一样说话，也不是讲那些没有多大用处而且让人头晕的理论。James以一种清晰且简单的方式给做这份工作的奇客们展示了TDD概念的方方面面，以及如何用C来实现它们。任何C程序员都能从这本书中获益。
—Michael “GeePaw” Hill
Anarchy Creek Software高级TDD教练
对于想学习TDD的C和C++开发者来说，这是第一本值得推荐的书，无论他们的目标系统是不是嵌入式平台。这本书就是这么好。
—C. Keith Ray
Industrial Logic公司敏捷教练、培训师
计算机\程序设计
我想这本书将成为嵌入式软件工程师的“圣经”。
——Robert C. Martin
对于想学习TDD的C和C++开发者来说，这是第一本值得推荐的书，无论他们的目标系统是不是嵌入式平台。这本书就是这么好。
——C. Keith Ray
Industrial Logic公司敏捷教练、培训师
测试驱动开发（TDD）是C语言开发人员需要掌握的一种现代编程实践。它是一种不同于以往的编程方法——在一种紧致的反馈循环中写出单元测试与产品代码。你在每分钟里都会得到有价值的反馈。你会在失误变成bug前就找到它们。你会尽早得到对设计问题的警告。你会马上发现副作用所带来的错误。你会有更多的时间花在为产品增加有价值的特性上。
James是为数不多的把测试驱动开发应用于嵌入式C的专家之一。他拥有15年在培训、教练以及实践用C、C++、Java和C#做测试驱动开发的经验，可以引领你从TDD的入门走向精通。
（美）James W. Grenning 著：James Grenning在全球范围内从事培训、教练以及咨询工作。他在软件开发的技术和管理方面拥有丰富的经验。他是把敏捷开发实践引入到嵌入式领域的带头人。他发明了计划扑克（Planning Poker）。他还是2001年2月《软件开发敏捷宣言》的原作者之一。
尹哲 等译：暂无简介
几年前我在Python中文社区（现在叫啄木鸟社区）第一次见到神作《Python的八荣八耻》，原文如下：
以动手实践为荣， 以只看不练为耻；
以打印日志为荣，以单步跟踪为耻；
以空格缩进为荣，以制表缩进为耻；
以单元测试为荣，以人工测试为耻；
以模块复用为荣，以复制粘贴为耻；
以多态应用为荣，以分支判断为耻；
以Pythonic为荣，以冗余拖沓为耻；
以总结分享为荣，以跪求其解为耻。
无论这段文字被贴到哪个流行的程序员论坛里，后面的跟帖里一半以上都是对第二条的质疑甚至声讨。其后演变出了版本更多、也更流行的“程序员的八荣八耻”。其中Pythonic是Python程序员的专有名词，自然会被改掉；无一例外，各个版本的“程序员的八荣八耻”都会把第二条“以打印日志为荣 , 以单步跟踪为耻 ”改掉。在我看来，这是买椟还珠。
“以打印日志为荣？干嘛打印日志？不会自己去代码里看吗？”
“以单步跟踪为耻？干嘛以单步跟踪为耻？在我们这儿会用调试器的都是牛人！”
“从前学C时用Turbo C调试，后来用VC，现在用gdb，挺好用的。”
“像我们用的这种嵌入式小众编译器，根本就没带调试工具。咱们想耻还没机会呢。”
“单步跟踪让代码的行为尽收眼底，是自己测试代码的最佳工具！”
单步跟踪，对于面对代码中的bug一筹莫展的程序员来讲的确是最后一根救命稻草，但同时也意味着程序员对于代码的行为不能完全掌控。如果需要请出调试器（或者用在代码中加printf的方式来调试，其作用和结果是一样的），那么往往就要花上几分钟甚至几天的时间才能定位到问题所在。如果能够根据系统或者测试所提供的日志（包括出错消息等）马上定位到问题，那么这几分钟到几天的时间就节省下来了。
“说起来容易，如何才能做到时刻掌控代码，把调试的需求减到最少？别忘了，我用的是C！”你需要读这本书——我的朋友James Grenning在本书中给出了有效又有趣的方法。
我把这段“八荣八耻”放在这里，读者开始一定以为是为了第四条“以单元测试为荣 , 以人工测试为耻”吧。这并不是一本专门讲测试的书，而是一本讲C语言程序设计的书。单元测试只是手段。
一直以来，测试驱动开发、重构、设计模式、处理遗留代码这些软件开发中优秀的工程实践都和C程序员无缘。作为C程序员和嵌入式开发程序员，很多实践方法都可以借鉴，但其中也会有很多问题。James是这方面不多见的专家，而这本书就是为这部分人而写的。
值得特别提出的是James花了相当的篇幅讲述了一些C语言特有的设计模式。这些设计模式并不是激进地完全面向对象，也不是花式繁多地包罗万象，是C语言程序设计不可多得的指南。
感谢James，在翻译本书的过程中我也受益良多。除了测试驱动开发本身，其中自然少不了印证中英文名词的对应。我想以后和别人讨论测试驱动开发时我不用再满嘴跑着英文单词了。感谢《xUnit测试模式》的作者Gerard Meszaros帮助我澄清了很多单元测试的概念，这对于准确翻译本书来讲很关键。值得一提的是在Gerard的概念里，test harness是指test framework（测试框架） + test case（测试用例）的集合，而在本书中我全部使用“测试框架”来翻译test harness，这也是James的本意。
感谢我的老东家诺基亚西门子通信技术有限公司。我在通信行业从事嵌入式软件开发工作十几年，其中大部分实践和经验来自那里。同时，我和James是在诺西的时候认识的。那时他教我们TDD，而我们用的正是C！还有诺西Coach Network的成员们，我们经常在一起探讨和实践这些方法。还有本书韩文版的译者严位相（Wisang），我们也曾一起做coding dojo来实践书中的方法。而且，我和Wisang一起在意大利餐馆点餐时都会心地一笑。我们为什么要笑？读完了本书你就知道了。
翻译这本书花了几个月的时间，感谢我妻子小米（郑秀雯）的大力支持。并且，是她帮助粗心大意的我校对译稿。
尹哲
推 荐 序 一
这本书轻而易举地成为同一主题中最好的书。这是一本友善的、易读的书，有以代码为中心的浓郁风格，用详细的例子引领读者从TDD的入门走向精通。它是对同类佳作的一个补充，因为这本书完全是关注在C语言上的，不像很多其他相关书籍，并且尤其针对我们这样写固件的人。
James没有跳过任何一步，他将带着你一直走过荆棘密布的细节。而且其中的讨论很实用，你不会因例子的特殊性而感到困惑。讨论中充满温馨的建议及出色的见地。他并不介意借鉴他人的智慧，这让本书有更完整的感觉。
TDD项目的早期让人觉得平平无奇，甚至漫无目的。你会写测试来确保大部分的元素都正确地工作。为什么这么麻烦地要去看一个基本上只是简单写入的操作是否正确工作？这种看上去就是浪费时间的东西曾让我极厌恶地把几本书扔在地板上，但是，James让亲爱的读者保持耐心，承诺会让我们看到它是个完备的过程并且能得到极佳的代码，而且他恪守了这个承诺。
TDD的确意味着你要深入到某个特定的方法或者特定的测试细节中去，这样往往会使手头的测试方向变得迷惑不清。如果你对TDD报悲观态度或者你是新手的话，请确保你读完了全书再下结论，因为只有这样你才能见到细节是如何变化成一个完整的系统的，而且它还带有稳定的测试。
这本书比其他任何一本同主题的书都优秀，它展示了TDD与更常见的“写一大堆代码然后再调试”的方式之间的对比。用后一种方式，我们是在患了溃疡还吃辣热狗，因为我们很久以前埋下的bug会随时间而变得更难发现。而另一方面，TDD则意味着今天的bug就是十分钟之前生成的。它们像跳脱衣舞的Gypsy Rose Lee一样。有测试失败了吗？嗯，问题肯定出在你最后做的那件事上。
TDD的强项之一是对边界条件的测试。我的嵌入式灾难档案中充满了棘手的代码错误，这些代码错误是由溢出、“偏了一个”或者诸如此类的原因造成的。TDD——或者说至少用James的方式——意味着让主路径工作起来并测试通过，然后再写测试来确保每个单一的边界条件也测试通过。以前通常来讲单元测试很少做得这么全面和有效。
嵌入式TDD围绕着创建一个测试框架而开展，也就是一个让程序员可以描述代码应该有怎样的行为的软件包。James把Unity和CppUTest都讲解得很细致（不要被名字迷惑，后者对C++和C都支持）。每个测试都会调用创建和拆除的例程来安装和移除所需的环境，例如，初始化一个缓冲区然后检查是否有缓冲区溢出。我发现这很酷。
这本书包括了积极的工作指南加上很多可行的建议和警句，例如“绿了之后就重构”（让代码先可以工作，当测试通过后，如果需要的话再改进代码）。这本书首先强调了在开发过程中的乐趣。这也是我们大多数在这个领域中的人会这样做的首要原因。
Jack Ganssle
推 荐 序 二
你会拿起这本书，因为你是一名嵌入式软件工程师。你不像其他程序员一样生活在多核、兆兆字节和亿次运算中。你生活在这样的工程师世界中：硬性限制、物理约束、微秒、微瓦特和千字节。你可能用C多于C++，因为你知道C编译器会生成什么。你可能在需要时会用上汇编语言，因为有时就算是C编译器对你来讲也太奢侈了。
那么，你能拿这本介绍测试驱动开发的书来做什么呢？你没有那种条件优越的环境，在那里程序员都养成了随处乱丢垃圾的习惯。事实上，TDD是给Java和Ruby程序员准备的。由TDD编写的代码在解释执行的语言和虚拟机上有用。它不是为那种直接在真材实料上运行的代码准备的，是吗？
我和Jame Greening在20世纪70年代后期和80年代早期开始接触嵌入式软件。我们一起为电话测试系统编写8085汇编程序，这个系统安装在电话中心办公室的机架上。我们在中心办公室的水泥地上度过了很多夜晚，伴随我们的是示波仪、逻辑分析仪，还有可编译存储器烧录仪。我们有32KB的RAM和32KB的ROM，我们在其中创造奇迹。我们做的那是怎样的奇迹啊！
在我们公司，我和James首先把C引入到嵌入式系统中。我们不得不和那些声称“C太慢了”的硬件工程师战斗。我们写出驱动程序、监控程序以及任务切换程序，使得我们的系统可以在被分成RAM和ROM的16位地址空间中运行。这花了几年的时间，但最后，我们看到了公司里所有新的嵌入式系统都是用C来写的。
在经历了20世纪70、80年代那段让人兴奋的日子后，我和James分别去了不同的公司。我游荡到了IT和产品的王国，在那里资源就像意大利婚礼上的红酒一样源源不断。但James对嵌入式世界情有独钟，因此在这过去的30多年里，James Grenning一直在嵌入式环境中写代码，例如数字电话交换机、高速复印机、无线控制器、移动电话等。
我和James在20世纪90年代后期再次合作。我和他在施乐公司做咨询，支持施乐运行在68000上的高端数字打印机上的嵌入式C++软件开发。James同时也在为一家知名的移动电话公司的通信子系统做咨询。
James不仅是卓有建树的嵌入式软件工程师，还是卓有建树的软件工匠。他非常关心他所写的代码和他所创造的产品。他也很关心他所在的行业。他的目标一直都是提高嵌入式开发的行业水平。
James参加了1999年举办的首次极限编程俱乐部活动。2001年在斯诺波得酝酿敏捷宣言时，James也参加了并且还是原文签署人之一。James决意致力于找到把敏捷软件开发的宝贵技术引入到嵌入式软件开发中的方法。
在过去的十年里，James参与了敏捷社区并致力于把敏捷软件开发中最好的思想集成到嵌入式软件开发当中。他已经把TDD介绍到了很多嵌入式公司中，并且帮助他们的工程师写出更好的、更可靠的嵌入式代码。
这本书是上述努力工作的结果。这本书是敏捷与嵌入式的结合。事实上，这本书的标题错了。它应当被叫做《用C打造嵌入式系统》，因为尽管这本书讲了很多TDD的内容，但它讲得比这个要多很多！这本书提供了一个非常完整的、高度专业的用C产生高质量嵌入式软件的方法，这个方法既快速又可靠。我想这本书将成为嵌入式软件工程的“圣经”。
是的，在嵌入式的世界里你也可以做TDD。不仅如此，你也应该做TDD！在这本书里，James会展示给你如何经济、有效和有益地利用TDD。他会展示给你所需的技术和窍门、纪律还有流程。还有，他还会展示代码给你看！
准备好读很多代码吧。这本书充满了代码。并且这些代码都是由一个满腹学识的工匠写出的。随着你通读本书以及所有的代码，James会教给你如何测试、设计原则、重构、代码中的坏味道、遗留代码管理、设计模式、测试模式，以及很多其他知识。
在这个基础上，这本书的代码几乎全部用C写成，并且百分之百可以用于嵌入式的、受约束的开发和执行环境。
因此，如果你是一个生活在真实的贴近硬件代码世界中脚踏实地的嵌入式工程师，那么，这本书就是为你而写。你已经拿起了它并读了这么多。为了完成本推荐序开始的时候介绍的事情，现在把其余的部分读完吧。
Robert C. Martin (Uncle Bob)
2010年10月
对本书的赞誉
译者序
推荐序一
推荐序二
前言
致谢
第1章 测试驱动开发1
1.1 为什么我们需要TDD2
1.2 什么是测试驱动开发3
1.3 TDD的机理4
1.4 TDD的微循环5
1.5 TDD的好处7
1.6 对于嵌入式开发的益处7
第一部分 开 始
第2章 测试驱动开发的工具和约定9
2.1 什么是自动化单元测试框架9
2.2 Unity：一个全部用C实现的自动化测试框架10
2.3 CppUTest：一个用C++实现的自动化单元测试框架16
2.4 单元测试也会崩溃19
2.5 “四阶段”模式19
2.6 我们到哪里了19
第3章 开始一个C语言模块21
3.1 具有可测性的C模块的那些元素21
3.2 LED驱动都做些什么22
3.3 写一个测试列表23
3.4 写第一个测试23
3.5 先测试驱动接口再测试驱动内部实现29
3.6 增量式前进34
3.7 测试驱动开发者的状态机36
3.8 测试要做到FIRST37
3.9 我们到哪里了37
第4章 一路测试直到完成39
4.1 从简单入手“生长”出解决方案39
4.2 保持代码整洁——边做边重构53
4.3 重复直到完成55
4.4 声明完成之前先向回走一步61
4.5 我们到哪里了61
第5章 嵌入式系统TDD策略63
5.1 目标硬件的瓶颈63
5.2 双目标开发的好处64
5.3 双目标测试的风险65
5.4 嵌入式的TDD循环65
5.5 双目标的不兼容性67
5.6 和硬件一起测试71
5.7 欲速则不达74
5.8 我们到哪里了74
第6章 是的，但是……75
6.1 我们没那个时间75
6.2 为什么不在写了代码之后再写测试77
6.3 测试也需要维护78
6.4 单元测试不能发现所有的bug78
6.5 我们的构建时间太长79
6.6 我们有现存的代码79
6.7 我们的内存有约束79
6.8 我们不得不和硬件交互80
6.9 为什么要用C++的测试框架来测试C81
6.10 我们到哪里了81
第二部分 测试有合作者的模块
第7章 测试替身83
7.1 合作者83
7.2 脱离依赖关系84
7.3 何时使用测试替身86
7.4 用C来仿冒，下一步88
7.5 我们到哪里了89
第8章 监视产品代码90
8.1 灯光调度测试列表90
8.2 对于硬件和操作系统的依赖91
8.3 链接时代换92
8.4 监视被测试代码93
8.5 控制时钟97
8.6 先0后198
8.7 处理多个的情况110
8.8 我们到哪里了115
第9章 运行时绑定的测试替身116
9.1 测试随机性116
9.2 冒仿函数指针118
9.3 外科手术般地插入间谍120
9.4 用间谍来校验输出124
9.5 我们到哪里了127
第10章 仿制对象129
10.1 闪存驱动程序129
10.2 MockIO136
10.3 测试驱动开发驱动程序138
10.4 模拟设备超时142
10.5 这值得吗144
10.6 用CppUMock来仿制144
10.7 生成仿制对象147
10.8 我们到哪里了148
第三部分 设计与持续改进
第11章 SOLID、灵活并可测试的设计149
11.1 SOLID设计原则150
11.2 C语言中的SOLID模型152
11.3 演进的需求和有问题的设计154
11.4 用动态接口来改进设计160
11.5 更灵活的基于类型的动态接口168
11.6 做多少设计才是足够的171
11.7 我们到哪里了173
第12章 重构174
12.1 软件的两个价值174
12.2 三项关键技能175
12.3 代码中的坏味道以及如何改进它们176
12.4 转化代码184
12.5 那性能和大小怎么办199
12.6 我们到哪里了201
第13章 为遗留代码加测试203
13.1 遗留代码改动准则203
13.2 童子军原则204
13.3 遗留代码改动步骤205
13.4 测试点206
13.5 两步结构体初始化209
13.6 崩溃直到通过211
13.7 鉴别测试216
13.8 为第三方代码做学习测试219
13.9 测试驱动缺陷修正220
13.10 增加策略测试221
13.11 我们到哪里了221
第14章 测试的模式与反模式223
14.1 “喋喋不休”测试反模式223
14.2 “拷贝－粘贴－调整－重复”反模式224
14.3 “格格不入的测试用例”反模式225
14.4 “测试组之间的重复”反模式227
14.5 “不尊重测试”反模式228
14.6 “行为驱动开发”测试模式228
14.7 我们到哪里了229
第15章 结束语230
第四部分 附 录
附录A 开发系统的测试环境233
附录B Unity快速索引237
附录C CppUTest快速索引241
附录D 开始之后的LedDriver245
附录E 操作系统隔离层的例子248
附录F 参考书目255
