《测试驱动的嵌入式C语言开发》——2.4节单元测试也会崩溃

2.4 单元测试也会崩溃
运行测试还有一个可能结果,那就是崩溃。通常意义上讲,C不是一种安全的语言。C代码可能会不知道跑到哪里,再也不返回了。sprintf()就是一个危险的函数。如果你传入的缓冲太小,内存就会被破坏。这个错误也许会让整个系统马上崩溃。它也可能会在以后崩溃。这时的行为很难说。结果是,一个测试可能无声息地运行通过并结束,或者提前退出运行但看上去没有错误,也可能是“嘣”地一声崩溃。
当你发现一个无声的失败或者崩溃的测试时,可以让测试框架来帮你确认是什么地方出了错。有时,一个对产品代码的改动会导致一个从前通过的测试失败,甚至崩溃。所以在崩溃之前,你要知道到底是哪个测试失败了。
因为测试框架除了测试失败以外通常都保持安静,当测试崩溃时,你可能不会得到什么有用的输出。Unity和CppUTest都提供了一个命令行参数来让测试运行于“冗余模式”(-v)。使用了-v,每个TEST()在运行前都会先写出自己的名字。结果是,最后一个涉及的TEST()就是引起崩溃的原因。
你还可以过滤测试组(-g testgroup)和测试用例(-n testname)。这会让你精确地知道是哪个测试用例在运行。这些对于寻找崩溃原因很有帮助。

时间: 2024-12-05 04:55:36

《测试驱动的嵌入式C语言开发》——2.4节单元测试也会崩溃的相关文章

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

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

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

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