《测试驱动的嵌入式C语言开发》——1.2节什么是测试驱动开发

1.2 什么是测试驱动开发
测试驱动开发(TDD)是一种增量式软件开发技术。简单地说,就是在没有失败的单元测试的前提下不可以写产品代码。这些测试要很小,而且要自动化。用测试来驱动其实很合理。相对于直接工作在产品代码上,TDD的实践者们会先用测试来表达他们希望产品代码会有什么样的行为。然后这个测试显然会失败。只有在这时,他们才开始写产品代码,以便让测试通过。
测试自动化是TDD的关键。在TDD的进程中,首先会生成新的自动化测试,紧跟着是满足这些测试的产品代码。一套单元测试伴随着产品代码同时不断增长,它也是像产品代码一样具有价值的资产。每次微小改动代码时,这套测试都会运行一次。这样不仅保证了新代码是可工作的,同时也保证了已存在的代码与新的改动兼容。
软件是很脆弱的,任何改动都可能产生意料之外的结果。如果只有手工测试,我们很难负担这么多测试来预防所有意料之外的情况发生。重新测试的代价太高了,所以我们只去运行那些我们认为必需的手工测试。有时我们没那么幸运,引入了bug却没发现。如果使用TDD,测试会帮我们检查这些意料之外的情况,我们不用放弃检查之前的那些代码的行为。
尽管你的确要写很多有价值的自动化测试,但是TDD并不是一种测试技术。它是解决编程问题的一种方法。它能帮助软件开发人员做出更好的设计决策。对于方向错误,或者疏漏了实际约束的解决方案,测试将会给出明确的警告。测试抓住了产品代码预期的行为。
TDD还很有趣!这就像一个游戏,你在技术迷宫中将软件引向高可靠的方向,同时还避免了无聊的调试过程。伴随着每一个测试的通过都会有新的成就感,并能感受到向目标更近了一步。自动化测试会记录那些假设,抓住决策,并且让我们能专心面对下一个挑战。

时间: 2024-09-24 04:19:19

《测试驱动的嵌入式C语言开发》——1.2节什么是测试驱动开发的相关文章

《测试驱动的嵌入式C语言开发》——第1章测试驱动开发

第1章 测试驱动开发我们都做过这样的事--写一大堆代码然后艰难地使它工作起来.也就是先建造再修正.测试是在代码写完之后的事情.测试总是一件后面加上来的事情,这也是我们过去唯一所知的方法.这种很难预料的过程被亲切地称为"调试"(debugging),我们可能会在其中花掉半个小时.调试的过程在我们的进度中被"测试"和"集成"粉饰起来.它总是风险和不确定的来源.修改一个bug可能导致产生另一个,有时是一系列其他的bug.我们往往会统计这些数据来预测把b

《测试驱动的嵌入式C语言开发》——1.6节对于嵌入式开发的益处

1.6 对于嵌入式开发的益处嵌入式软件开发面临所有"通常意义上"的软件开发的挑战.例如很难把进度计划做得好且可靠.但嵌入式软件开发也有其自身特有的更多挑战.这并不意味着嵌入式开发不能采用TDD.嵌入式开发者最常引用的借口是嵌入式代码依赖于硬件.依赖关系对于非嵌入式代码也是个大问题.幸运的是,我们有办法来解决这些依赖问题.原则上讲,对硬件设备的依赖和对数据库的依赖没什么区别.嵌入式开发者面临很多挑战,我们将展开讨论如何从TDD借力.嵌入式开发者不仅能收到前面讲过的那些非嵌入式开发者能享受

《测试驱动的嵌入式C语言开发》——3.5节先测试驱动接口再测试驱动内部实现

3.5 先测试驱动接口再测试驱动内部实现好的接口对于设计良好的模块来讲很关键.前面几个测试会驱动接口设计.关注于接口意味着我们是从外向内开发代码的.测试作为接口的首个用户,从调用者(或客户端代码)的角度给出了开发代码的使用方式.从使用者的角度出发会产生可用性更强的接口.我通常也会让前面的几个测试来检验一些产品代码的边界条件.选择一个带边界检查的简单用例. 为了消除这个编译错误,在模块的接口声明头文件中增加这个接口函数原型: 写出并且通过这些测试能帮助我们实现以下目标:它定义了驱动程序的一个接口函

《测试驱动的嵌入式C语言开发》——3.6节增量式前进

3.6 增量式前进 刚刚接触TDD的人往往为这样的早期版本代码而感到困惑."我们什么也没有测到(你可能这样想),这只是些硬编码的返回值":"或者测试太小了,我们只是在各种活动间跳来跳去".让我来进一步解释. DTSTTCPW:先仿冒再建造 回首我刚刚学习极限编程时,Kent Beck在黑板上写下了这个很到位的缩写:DTSTTCPW.它读起来还蛮押韵的:我希望我也能找到那么押韵的一组词.它是Do The Simplest Thing That Could Possib

《测试驱动的嵌入式C语言开发》——2.2节Unity:一个全部用C实现的自动化测试框架

2.2 Unity:一个全部用C实现的自动化测试框架Unity是一个简单且直接的自动化单元测试框架.它由很少的几个文件构成.让我们通过几个示例单元测试用例来认识一下Unity和单元测试.如果你是一个长期的Unity用户,你会发现如果不用Unity所提供的脚本来生成测试运行容器,那么额外的几个宏可能会很有帮助.用Unity写的sprintf()测试用例 测试要写得短并且有重点.可以把它想象成一个安检过程,通过时保持安静,失败时就要发出警报声.下面这个测试让sprintf()处理一个没有格式操作的格

《测试驱动的嵌入式C语言开发》——3.4节写第一个测试

3.4 写第一个测试现在测试列表已经有了,我们可以开始了.很自然,第一个测试是去测试初始化是否正确.LED在初始化后应当全部关闭.首先我们要建立LedDriver测试文件.按照惯例,可以将它命名为LedDriverTest.c.我通常把测试代码放在一个与产品代码不同的目录里.我会把这些代码放在unity/LedDriver目录中,并调整makefile从而让它能编译和链接这个新的测试文件.给测试起个合适的名字来反映我们要实现的目标,这个文件看起来如下所示: 现在让测试检查一些有意义的东西.看一下

《测试驱动的嵌入式C语言开发》——1.1节为什么我们需要TDD

1.1 为什么我们需要TDDZune是微软用来与iPod竞争的产品.如果使用测试驱动开发就可能阻止一个在Zune中令人尴尬的bug.2008年12月31日这一天,Zune变成了一块砖头.这个日子有什么特别的吗?那天是新年前夜,闰年的最后一天,也是30GB Zune经历过的第一个闰年.很多人分析了Zune的这个bug,并且最终定位问题到时钟驱动程序中的一个函数.尽管下面的例子不是实际的那个驱动程序代码,但这段代码有着相同的bug. 很多代码阅读方面的专家在看过这段代码后得出了和我一样的错误结论.我

《测试驱动的嵌入式C语言开发》——2.5节 “四阶段”模式

2.5 "四阶段"模式在Gerard Meszaros所著的<xUnit Testing Patterns>一书中,他描述了"四阶段"测试模式,我将贯穿于本书使用这种模式.这种模式的目的是创建明确.可读并且结构良好的测试.如果你遵循这个模式,阅读测试的人会很快明白要测试的是什么.Gerard的四个阶段分别是: 建立:创建测试的前置条件. 运行:对系统进行操作. 验证:检查预期的输出. 拆卸:把被测系统恢复到测试前的初始状态.为了让测试过程清晰.明了,要让

《测试驱动的嵌入式C语言开发》——导读

目 录 第1章 测试驱动开发1.1 为什么我们需要TDD1.2 什么是测试驱动开发1.3 TDD的机理1.4 TDD的微循环1.5 TDD的好处1.6 对于嵌入式开发的益处第一部分 开 始第2章 测试驱动开发的工具和约定2.1 什么是自动化单元测试框架2.2 Unity:一个全部用C实现的自动化测试框架2.3 CppUTest:一个用C++实现的自动化单元测试框架2.4 单元测试也会崩溃2.5 "四阶段"模式2.6 我们到哪里了第3章 开始一个C语言模块3.1 具有可测性的C模块的那些

《测试驱动的嵌入式C语言开发》——2.3节CppUTest:一个用C++实现的自动化单元测试框架

2.3 CppUTest:一个用C++实现的自动化单元测试框架现在你已经见过了Unity,接下来我会快速介绍一下CppUTest,同时也是我更倾向于使用的对C和C++代码进行单元测试的自动化测试框架.事实上,不仅因为它是一个功能全面的测试框架,同时也因为我是CppUTest的作者之一.本书开始的几个例子会用Unity,在第8章之后会使用CppUTest.CppUTest是为了支持在多种操作系统上开发嵌入式软件而特别设计的.CppUTest的宏被设计成不需要了解C++也可以写测试用例.这使得C程序