测试驱动的嵌入式C语言开发
点击看大图基本信息
- 作者： (美)James W. Grenning [作译者介绍]
- 译者： 尹哲
- 丛书名： 开发人员专业技术丛书
- 出版社：机械工业出版社
- ISBN：9787111366232
- 上架时间：2012-2-9
- 出版日期：2012 年1月
- 开本：16开
- 页码：256
- 版次：1-1
- 所属分类：
计算机 > 计算机组织与体系结构 > 嵌入式计算机
计算机 > 软件与程序设计 > C/Turbo C > C
合作专区 > 微软技术图书 > 微软程序设计 > 微软C/C++/VC++
内容简介回到顶部↑
书籍
计算机书籍
《测试驱动的嵌入式c语言开发》深入介绍如何把测试驱动的开发方法应用于嵌入式c语言开发，第一部分介绍了两个开源的测试框架，通过测试驱动开发方法开发第一个模块；第二部分深入介绍了与系统中其他模块进行交互的代码的测试技术，如测试替身、仿制对象等；第三部分介绍了设计与持续改进代码，如写出更好代码的一些重要原则，建立可测并灵活设计的高级技术，改进已有代码的实践方法—重构技术，改进遗留代码，以及编写和维护测试的指导原则。本书的代码几乎全部用c写成，并且可以用于嵌入式的、受约束的开发和执行环境。
《测试驱动的嵌入式c语言开发》是作者多年实践经验的总结，实用性强，适合嵌入式c/c++语言程序员、工程师阅读。
计算机书籍
《测试驱动的嵌入式c语言开发》深入介绍如何把测试驱动的开发方法应用于嵌入式c语言开发，第一部分介绍了两个开源的测试框架，通过测试驱动开发方法开发第一个模块；第二部分深入介绍了与系统中其他模块进行交互的代码的测试技术，如测试替身、仿制对象等；第三部分介绍了设计与持续改进代码，如写出更好代码的一些重要原则，建立可测并灵活设计的高级技术，改进已有代码的实践方法—重构技术，改进遗留代码，以及编写和维护测试的指导原则。本书的代码几乎全部用c写成，并且可以用于嵌入式的、受约束的开发和执行环境。
《测试驱动的嵌入式c语言开发》是作者多年实践经验的总结，实用性强，适合嵌入式c/c++语言程序员、工程师阅读。
作译者回到顶部↑
本书提供作译者介绍
James W．Grenning 在全球范围内从事培训以及咨询工作。他在软件开发的技术和管理方面拥有丰富的经验。他是把敏捷开发实践引入到嵌入式领域的带头人。他发明了计划扑克(Planning Poker)。他还是2001年2月《软件开发敏捷宣言》的作者之一。
尹哲 是Odd-e．com团队中的一名敏捷教练。他在世界各地从事培训和软件项目咨询，如测试驱动开发、系统工程实践以及分析实践等。他在敏捷与精益教练方面拥有丰富经验，在研发管理和软件设计这两方面也造诣颇深。他同时还是敏捷社区和开源软件的积极参与者。.. << 查看详细
尹哲 是Odd-e．com团队中的一名敏捷教练。他在世界各地从事培训和软件项目咨询，如测试驱动开发、系统工程实践以及分析实践等。他在敏捷与精益教练方面拥有丰富经验，在研发管理和软件设计这两方面也造诣颇深。他同时还是敏捷社区和开源软件的积极参与者。.. << 查看详细
目录回到顶部↑
《测试驱动的嵌入式c语言开发》
对本书的赞誉
译者序
推荐序一
推荐序二
前言
致谢
第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
对本书的赞誉
译者序
推荐序一
推荐序二
前言
致谢
第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
译者序回到顶部↑
几年前我在Python中文社区（现在叫啄木鸟社区）第一次见到神作《Python的八荣八耻》，原文如下：
以动手实践为荣， 以只看不练为耻；
以打印日志为荣，以单步跟踪为耻；
以空格缩进为荣，以制表缩进为耻；
以单元测试为荣，以人工测试为耻；
以模块复用为荣，以复制粘贴为耻；
以多态应用为荣，以分支判断为耻；
以Pythonic为荣，以冗余拖沓为耻；
以总结分享为荣，以跪求其解为耻。
无论这段文字被贴到哪个流行的程序员论坛里，后面的跟帖里一半以上都是对第二条的质疑甚至声讨。其后演变出了版本更多、也更流行的“程序员的八荣八耻”。其中Pythonic是Python程序员的专有名词，自然会被改掉；无一例外，各个版本的“程序员的八荣八耻”都会把第二条“以打印日志为荣 , 以单步跟踪为耻 ”改掉。在我看来，这是买椟还珠。
“以打印日志为荣？干嘛打印日志？不会自己去代码里看吗？”
“以单步跟踪为耻？干嘛以单步跟踪为耻？在我们这儿会用调试器的都是牛人！”
“从前学C时用Turbo C调试，后来用VC，现在用gdb，挺好用的。”
“像我们用的这种嵌入式小众编译器，根本就没带调试工具。咱们想耻还没机会呢。”
“单步跟踪让代码的行为尽收眼底，是自己测试代码的最佳工具！”
单步跟踪，对于面对代码中的bug一筹莫展的程序员来讲的确是最后一根救命稻草，但同时也意味着程序员对于代码的行为不能完全掌控。如果需要请出调试器（或者用在代码中加printf的方式来调试，其作用和结果是一样的），那么往往就要花上几分钟甚至几天的时间才能定位到问题所在。如果能够根据系统或者测试所提供的日志（包括出错消息等）马上定位到问题，那么这几分钟到几天的时间就节省下来了。
“说起来容易，如何才能做到时刻掌控代码，把调试的需求减到最少？别忘了，我用的是C！”你需要读这本书——我的朋友James Grenning在本书中给出了有效又有趣的方法。
我把这段“八荣八耻”放在这里，读者开始一定以为是为了第四条“以单元测试为荣 , 以人工测试为耻”吧。这并不是一本专门讲测试的书，而是一本讲C语言程序设计的书。单元测试只是手段。
一直以来，测试驱动开发、重构、设计模式、处理遗留代码这些软件开发中优秀的工程实践都和C程序员无缘。作为C程序员和嵌入式开发程序员，很多实践方法都可以借鉴，但其中也会有很多问题。James是这方面不多见的专家，而这本书就是为这部分人而写的。
值得特别提出的是James花了相当的篇幅讲述了一些C语言特有的设计模式。这些设计模式并不是激进地完全面向对象，也不是花式繁多地包罗万象，是C语言程序设计不可多得的指南。
以动手实践为荣， 以只看不练为耻；
以打印日志为荣，以单步跟踪为耻；
以空格缩进为荣，以制表缩进为耻；
以单元测试为荣，以人工测试为耻；
以模块复用为荣，以复制粘贴为耻；
以多态应用为荣，以分支判断为耻；
以Pythonic为荣，以冗余拖沓为耻；
以总结分享为荣，以跪求其解为耻。
无论这段文字被贴到哪个流行的程序员论坛里，后面的跟帖里一半以上都是对第二条的质疑甚至声讨。其后演变出了版本更多、也更流行的“程序员的八荣八耻”。其中Pythonic是Python程序员的专有名词，自然会被改掉；无一例外，各个版本的“程序员的八荣八耻”都会把第二条“以打印日志为荣 , 以单步跟踪为耻 ”改掉。在我看来，这是买椟还珠。
“以打印日志为荣？干嘛打印日志？不会自己去代码里看吗？”
“以单步跟踪为耻？干嘛以单步跟踪为耻？在我们这儿会用调试器的都是牛人！”
“从前学C时用Turbo C调试，后来用VC，现在用gdb，挺好用的。”
“像我们用的这种嵌入式小众编译器，根本就没带调试工具。咱们想耻还没机会呢。”
“单步跟踪让代码的行为尽收眼底，是自己测试代码的最佳工具！”
单步跟踪，对于面对代码中的bug一筹莫展的程序员来讲的确是最后一根救命稻草，但同时也意味着程序员对于代码的行为不能完全掌控。如果需要请出调试器（或者用在代码中加printf的方式来调试，其作用和结果是一样的），那么往往就要花上几分钟甚至几天的时间才能定位到问题所在。如果能够根据系统或者测试所提供的日志（包括出错消息等）马上定位到问题，那么这几分钟到几天的时间就节省下来了。
“说起来容易，如何才能做到时刻掌控代码，把调试的需求减到最少？别忘了，我用的是C！”你需要读这本书——我的朋友James Grenning在本书中给出了有效又有趣的方法。
我把这段“八荣八耻”放在这里，读者开始一定以为是为了第四条“以单元测试为荣 , 以人工测试为耻”吧。这并不是一本专门讲测试的书，而是一本讲C语言程序设计的书。单元测试只是手段。
一直以来，测试驱动开发、重构、设计模式、处理遗留代码这些软件开发中优秀的工程实践都和C程序员无缘。作为C程序员和嵌入式开发程序员，很多实践方法都可以借鉴，但其中也会有很多问题。James是这方面不多见的专家，而这本书就是为这部分人而写的。
值得特别提出的是James花了相当的篇幅讲述了一些C语言特有的设计模式。这些设计模式并不是激进地完全面向对象，也不是花式繁多地包罗万象，是C语言程序设计不可多得的指南。
前言回到顶部↑
我第一次接触测试驱动开发（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中可以找到编译示例代码的指导。
像很多嵌入式开发工程一样，产品的发布因为软件开发而受阻并不是什么新鲜事儿。但我们那时没有办法开始工作却是因为硬件和操作系统还没确定，或者说还没准备就绪。项目整体的进度因而一天天延期。我们一再被重新召集到一起，因为目标硬件这个瓶颈让进度像点滴一样缓慢。 除了开会、交谈、争论或者把我们想做的软件写成文档，我们还能做什么？事实是，还有很多事情可以做。
所有的嵌入式开发人员都经历过目标硬件瓶颈。通常硬件和软件是并行开发的，并且在开发过程的大部分时间里是不可用的。更糟的是，硬件和软件中都有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中可以找到编译示例代码的指导。
序言回到顶部↑
推 荐 序 一
这本书轻而易举地成为同一主题中最好的书。这是一本友善的、易读的书，有以代码为中心的浓郁风格，用详细的例子引领读者从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一直在嵌入式环境中写代码，例如数字电话交换机、高速复印机、无线控制器、移动电话等。
这本书轻而易举地成为同一主题中最好的书。这是一本友善的、易读的书，有以代码为中心的浓郁风格，用详细的例子引领读者从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 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教练
—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教练
【插图】
加载中...
