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

1.6 对于嵌入式开发的益处
嵌入式软件开发面临所有“通常意义上”的软件开发的挑战。例如很难把进度计划做得好且可靠。但嵌入式软件开发也有其自身特有的更多挑战。这并不意味着嵌入式开发不能采用TDD。
嵌入式开发者最常引用的借口是嵌入式代码依赖于硬件。依赖关系对于非嵌入式代码也是个大问题。幸运的是,我们有办法来解决这些依赖问题。原则上讲,对硬件设备的依赖和对数据库的依赖没什么区别。
嵌入式开发者面临很多挑战,我们将展开讨论如何从TDD借力。嵌入式开发者不仅能收到前面讲过的那些非嵌入式开发者能享受到的好处,同时还将得到一些嵌入式特别的好处:
在硬件可用之前或者硬件很贵或者很稀少时,通过独立于硬件的方式校验产品代码,从而降低风险。
在开发环境中执行并移除bug,从而减少长时间的编译、链接和上传这样的循环的次数。
对于在目标硬件中既难发现又难修改的问题,可以减少调试的时间。
通过在测试中模型化硬件交互,使硬件/软件的交互彼此独立。
通过解开模块之间以及模块与硬件之间的耦合来改进软件设计。可测试的代码首先必须是模块化的。
本书的第一部分将重点帮助你开始进行TDD。在接下来两章的一个TDD编程示例之后,我们将在第5章中更多地讨论为嵌入式软件做TDD的技术。

时间: 2024-09-22 20:11:58

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

《测试驱动的嵌入式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语言开发》——第1章测试驱动开发

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

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

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

《Android深度探索(卷1):HAL与驱动开发》——6.5节使用Eclipse开发和测试Linux驱动程序

6.5 使用Eclipse开发和测试Linux驱动程序 Android深度探索(卷1):HAL与驱动开发 在前面几节开发的word_count驱动和测试程序大多都需要在Linux终端进行编译(Android应用程序除外)和运行,而且也无法跟踪到Linux内核函数.变量.宏的内部(除非自己到Linux内核源代码中就寻找这些源代码文件),这并不利于深入了解Linux内核技术.在本节将为读者展示如何在Eclipse中开发Linux驱动程序,并且可以像跟踪Java代码一样直接跟踪到Linux内核源代码.