《测试驱动的嵌入式C语言开发》——3.8节测试要做到FIRST

3.8 测试要做到FIRST
在Agile in a Flash[OL11]一书中,Tim Ottinger和Jeff Langr给我们讲述了5个单元测试的关键属性。高效的测试需要做到FIRST。
F Fast(快速的): 测试要快速,快到程序员可以在每个微小的改动后都运行它们而且不会打断工作流。
I Isolated(独立的): 测试用例要是独立的。一个测试不会为另一个测试创建环境。测试中的失败也要分离开。
R Repeatable (可重复的): 测试要可以重复地去运行。可重复意味着自动化。一个循环中的测试总是给出同样的结果。
S Self-verifying(自校验的): 测试会自己检查产出,通过时只给出简单的“OK”,失败时给出详细的细节。
T Timely(及时的): 测试要及时做。程序员要及时写测试,与写产品代码紧连(但必须是在前面)来防止软件bug的产生。
这对于用C来做测试驱动开发来讲很有挑战。TDD最容易应用在完备的功能单元上,而对于通常的C编程实践来讲,常常缺失完备的功能单元。模块的边界不是很清楚,并且语言本身的结构对此的帮助很有限。
在面向对象语言中,函数围绕着通用的数据而聚集在一起,数据由函数定义的接口来访问。语言本身直接支持完备单元。完备单元的可测性更好。这就是为什么TDD在应用于面向对象的编程语言时更自然的原因。虽然C并不是面向对象语言,但是这并不能阻止我们从面向对象世界中学到有价值的知识。
当我们的测试做到了FIRST,那么它将引导我们产出模块化的设计,这样的设计支持当前的测试。让我们拭目以待,来看如何让代码模块化并可测。

时间: 2024-09-20 22:10:10

《测试驱动的嵌入式C语言开发》——3.8节测试要做到FIRST的相关文章

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

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

《测试驱动的嵌入式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语言开发》——第3章开始一个C语言模块

第3章 开始一个C语言模块在本章里,我会带你浏览用测试驱动来开发一个新的C模块首先要经历的那些步骤.在第4章里,我们则会全速前进来完成这个模块.从这一章开始并且贯穿本书,我们会关注到底能不能实现Dijkstra的不引入bug的愿景.我们所用的工具就是TDD.

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

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

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

3.3 写一个测试列表在开发新功能之前先创建一个测试列表会很有帮助.测试列表由需求衍生而来.测试列表定义了你对将需要完成的功能的最好的理解.这个列表不需要很完美.它只是个临时的文档,可能只记在一张卡片上或者笔记本上.你也可以直接把它当做注释输入到测试文件中.随着每个测试的添加,对应的注释将被删除.不要在写作这个列表上花太多时间,对于LED驱动程序来讲,花几分钟即可.我的初始测试列表如图3-1所示.在我们开始之前,先列出我们都需要测试什么. 请当心在创建测试列表时的报酬递减(diminishing

《测试驱动的嵌入式C语言开发》——2.6节我们到哪里了

2.6 我们到哪里了到这里,你应当对Unity和CppUTest的概况有了很好的了解,并且明白了如何用测试夹具和测试用例来定义测试.到目前为止你还没有看到测试驱动开发(TDD),为sprintf()写的那些测试并不是TDD,因为sprintf()是已经存在的代码.请你把新学到的知识运用到接下来的练习中.在接下来的两章中我们会用测试驱动来开发一些新代码.学以致用 在开发平台上建立一个测试环境.你可以从附录A中得到一些帮助.下载书中的代码,并运行makefile.可以访问本书的主页找到书中的代码:

《测试驱动的嵌入式C语言开发》——3.10节学以致用

学以致用 重新编写一个你自己的LedDriver,以便在第4章中使用.你可以在code/SandBox中找到开始所需的文件.其中有一个README.txt文件可以参考. 为一个内容为整型的先入先出的环状缓冲CircularBuffer写一个测试列表. 开始测试驱动开发CircularBuffer.选择检查初始状态并使用其接口的那些测试来做TDD.选择那些可以只用硬编码返回值就能通过的测试.你会需要修改makefile让它能够找到CircularBuffer的文件.在第4章之后你将会有机会完整地实

《测试驱动的嵌入式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.7节测试驱动开发者的状态机

3.7 测试驱动开发者的状态机可以把TDD想象成在一个状态机(state machine)里工作,就如图3-2所示.在这一过程的每一步中,你只需关注解决一个具体的问题.首先,你要决定下一个增量的行为是什么并用测试表达你所期望的产出.然后你要满足编译的要求,也就是设计接口并让头文件和测试之间达成一致(有时你所选择的名字已经在其他地方用过了,你会在这一步中发现这类问题). 在接口和测试之间达成一致后,预期会得到一个链接错误,之后就要增加一个骨架实现,但并不期望它是正确的实现.测试失败是一个好的信号,