C语言单元測试

对于敏捷开发来说,单元測试不可缺少,对于Java开发来说,JUnit非常好,对于C++开发,也有CPPUnit可供使用,而对于传统的C语言开发,就没有非常好的工具可供使用,能够找到的有这么几个工具:

  1. CuTest -- CuTest(Cute Test)是一个很easy的C语言单元測试工具。在使用它的时候,仅仅须要包括两个文件“CuTest.c CuTest.h”,然后就能够写測试用例,进行測试了。它对用例差点儿没有管理功能,报表输出也很easy,能够用来试验单元測试的基本想法。
  2. CUnit -- CUnit是一个轻型的C语言单元測试框架。它提供了设计、管理、执行測试用例的功能。它的报表功能比較强大,可是比較麻烦,更适合于较大一些的项目。
  3. Check -- 不错的工具。
    在这里(http://www.laatuk.com/tools/testing_tools.html)给出了各种软件測试工具,没事能够研究一下。

CUnit

这里主要讲CUnit在Linux平台下的应用。这里有一篇 CUnit測试工具使用 ,还有一篇 C单元測试包设计与实现 讲的不错,能够看一下。CUnit的主页是 http://cunit.sourceforge.net/index.html
CUnit以静态库的形式提供给用户使用,用户编敲代码的时候直接链接此静态库就能够了。它提供了一个简单的单元測试框架,而且为经常使用的数据类型提供了丰富的断言语句支持。

CUnit基本架构

Test Registry
                            |
             ------------------------------
             |                            |
          Suite ‘1‘      . . . .       Suite ‘N‘
             |                            |
       ---------------             ---------------
       |             |             |             |
    Test ‘11‘ ... Test ‘1M‘     Test ‘N1‘ ... Test ‘NM‘

一次測试(Test Registry)能够执行多个測试包(Test Suite),而每一个測试包能够包括多个測试用例(Test Case),每一个測试用例又包括一个或者多个断言类的语句。详细到程序的结构上,一次測试下辖多个Test Suite,它相应于程序中各个独立模块;一个Suite管理多个Test Case,它相应于模块内部函数实现。每一个Suite能够含有setup和teardown函数,分别在执行suite的前后调用。

CUnit測试模式

CUnit使用四种不同的接口,供用户来执行測试和汇报測试结果:

  1. 自己主动输出到XML文件,     非交互式
  2. 基本扩展编程方式,        非交互式
  3. 控制台方式,              交互式
  4. Curses图形接口,          交互式

注意1和2是非交互式的,4仅仅能在Unix下使用,经常使用console,并且console是能够人机交互的。

CUnit測试流程

使用CUnit进行測试的基本流程例如以下所看到的:

  1. 书写代測试的函数(假设必要,须要写suite的init/cleanup函数)
  2. 初始化Test Registry - CU_initialize_registry()
  3. 把測试包(Test Suites)添?到Test Registry - CU_add_suite()
  4. 添?測试用例(Test Case)到測试包其中 - CU_add_test()
  5. 使用适当的接口来执行測试測试程序,比如 CU_console_run_tests()
  6. 清除Test Registry - CU_cleanup_registry()

CUnit使用范例

CUnit的在线文档是 http://cunit.sourceforge.net/doc/index.html ,上面有着具体的论述。这里以使用自己主动产生XML文件的接口为例,讲述CUnit-2.1-0在Linux平台下的使用。
我要測试的是整数求最大值的函数maxi,我使用例如以下文件组织结构:

  1. func.c :定义maxi()函数
  2. test_func.c :定义測试用例和測试包
  3. run_test.c :调用CUnit的Automated接口执行測试
  4. Makefile :生成測试程序。

这样组织的优点是,我们能够把各个功能分离,当要改变待測试函数的定义的时候,我们仅仅须要改动func.c,而要增减、改动測试用例,仅仅改动test_func.c就能够了,要使用CUnit提供的别的API,那就改动run_test.c。

它们的内容分别例如以下所看到的:

1) func.c

/**//**
 * file: func.c
 **/

int maxi(int i, int j)
...{
        //return i>j?i:j;
        return i;
}

2) test_func.c

/**//**
 * file: test_func.c
 **/
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include "CUnit/CUnit.h"
#include "CUnit/Automated.h" 

/**//*---- functions to be tested ------*/
extern int maxi(int i, int j); 

/**//*---- test cases ------------------*/
void testIQJ()
...{
        CU_ASSERT_EQUAL(maxi(1,1),1);
        CU_ASSERT_EQUAL(maxi(0,-0),0);
}
 
void testIGJ()
...{
        CU_ASSERT_EQUAL(maxi(2,1),2);
        CU_ASSERT_EQUAL(maxi(0,-1),0);
        CU_ASSERT_EQUAL(maxi(-1,-2),-1);
}
 
void testILJ()
...{
        CU_ASSERT_EQUAL(maxi(1,2),2);
        CU_ASSERT_EQUAL(maxi(-1,0),0);
        CU_ASSERT_EQUAL(maxi(-2,-1),-1);


CU_TestInfo testcases[] = ...{
        ...{"Testing i equals j:", testIQJ},
        ...{"Testing i greater than j:", testIGJ},
        ...{"Testing i less than j:", testILJ},
        CU_TEST_INFO_NULL
};
 

/**//*---- test suites ------------------*/
int suite_success_init(void) ...{ return 0; }
int suite_success_clean(void) ...{ return 0; } 

CU_SuiteInfo suites[] = ...{
        ...{"Testing the function maxi:", suite_success_init, suite_success_clean, testcases},
        CU_SUITE_INFO_NULL
};
 

/**//*---- setting enviroment -----------*/

void AddTests(void)
...{
        assert(NULL != CU_get_registry());
        assert(!CU_is_test_running());
        /**//* shortcut regitry */

        if(CUE_SUCCESS != CU_register_suites(suites))...{
                fprintf(stderr, "Register suites failed - %s ", CU_get_error_msg());
                exit(EXIT_FAILURE);
        }
}

3) run_test.c

/**//**
 * file: run_test.c
 **/

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

int main( int argc, char *argv[] )
...{
       if(CU_initialize_registry())...{
                fprintf(stderr, " Initialization of Test Registry failed. ");
                exit(EXIT_FAILURE);
        }else...{
                AddTests();
                CU_set_output_filename("TestMax");
                CU_list_tests_to_file();
                CU_automated_run_tests();
                CU_cleanup_registry();
        }
        return 0;
}

4) Makefile

INC=-I/home/lirui/local/include
LIB=-L/home/lirui/local/lib

all: func.c test_func.c run_test.c
        gcc -o test $(INC) $(LIB)-lcunit -lcurses -static $^

因为CUnit是以库的形式提供的,所以我们在编译和链接的时候须要指明头文件和库所在的位置,又因为使用了Curses库,所以也要指定这个。

測试报告

执行上面产生的test程序,会在当前文件夹下产生两个xml文件:

  1. TestMax-Listing.xml :对測试用例的报告
  2. TestMax-Results.xml :对測试结果的报告

要查看这两个文件,须要使用例如以下xsl和dtd文件:CUnit-List.dtd和CUnit-List.xsl用于解析列表文件, CUnit-Run.dtd和CUnit-Run.xsl用于解析结果文件。这四个文件在CUnit包里面有提供,安装之后在$(PREFIX) /share/CUnit文件夹下,在我的配置其中,它在/home/lirui/local/share/CUnit文件夹下。在查看结果之前,须要把这六个文件:TestMax-Listing.xml, TestMax-Results.xml, CUnit-List.dtd, CUnit-List.xsl, CUnit-Run.dtd, CUnit-Run.xsl复制到一个文件夹下,然后用浏览器打开两个结果的xml文件就能够了。

1) TestMax-Listing.xml在IE其中显演示样例如以下:

2) TestMax-Results.xml在IE其中显演示样例如以下:

C语言单元測试,布布扣,bubuko.com

时间: 2024-07-31 08:17:56

C语言单元測试的相关文章

简单单元測试思想

一个项目又非常多模块组成,当我们每次完毕一个模块的时候,就应该測试该功能是否 可以执行正确.然后再写下一个模块,不要等全部模块写完了再总体測试,这样到时候非常 难找到问题(当然高手除外). 所以作为一个project师,写測试用例是一个主要的技能. 那怎样写測试用例呢? 事实上就是使用自己的模块,看执行的结果是否跟期望的结果一致. 比方例如以下,写了一个add函数,要測试它,我们写一个test_add函数. #include <stdio.h> int add(int a,int b) { r

Android 进行单元測试难在哪-part3

原文链接 : HOW TO MAKE OUR ANDROID APPS UNIT TESTABLE (PT. 1) 原文作者 : Matthew Dupree 译文出自 : 开发技术前线 www.devtf.cn 译者 : chaossss 校对者: tiiime 状态 : 完毕 在 Android 应用中进行单元測试非常困难.有时候甚至是不可能的.在之前的两篇博文中,我已经向大家解释了在 Android 中进行单元測试如此困难的原因.而上一篇博文我们通过分析得到的结论是:正是 Google 官

利用Continuous Testing实现Eclipse环境自己主动单元測试

当你Eclipse环境中改动项目中的某个方法时,你可能因为各种原因没有执行单元測试,结果代码提交,悲剧就可能随之而来. 所幸infinitest(http://infinitest.github.io/)提供了一个Continuous Testing插件,以及时自己主动执行单元測试.尽管会多占一些CPU资源,但开发者的硬件谁会不留一点余地呢?大不了,音乐.视频.360卸载就OK了.安装方法有两种: (1)使用"Install new software",输入地址:http://infi

玩转单元測试之WireMock -- Web服务模拟器

WireMock 是一个灵活的库用于 Web 服务測试,和其它測试工具不同的是.WireMock 创建一个实际的 HTTPserver来执行你的 Web 服务以方便測试. 它支持 HTTP 响应存根.请求验证.代理/拦截.记录和回放. 而且能够在单元測试下使用或者部署到測试环境. 它能够用在哪些场景下: 測试移动应用依赖于第三方REST APIs 创建高速原型的APIs 注入否则难于模拟第三方服务中的错误 不论什么单元測试的代码依赖于web服务的 文件夹 前提条件 Maven配置 准备工作 Ex

在Eclipse中使用JUnit4进行单元測试(0基础篇)

本文绝大部分内容引自这篇文章: http://www.devx.com/Java/Article/31983/0/page/1 我们在编写大型程序的时候,须要写成千上万个方法或函数,这些函数的功能可能非常强大,但我们在程序中仅仅用到该函数的一小部分功能,而且经过调试能够确定,这一小部分功能是正确的.可是,我们同一时候应该确保每个函数都全然正确,由于假设我们今后假设对程序进行扩展,用到了某个函数的其它功能,而这个功能有bug的话,那绝对是一件非常郁闷的事情.所以说,每编写完一个函数之后,都应该对这

新手学測试----Unit Test(单元測试)

在程序猿做项目的过程中,每当完毕一个功能,首先自己须要对完毕的功能进行測试.我如今正在做的项目用的工具是VS2012.那么接下来,就说一说在VS2012中是怎样创建单元測试的. 怎样创建单元測试? 在VS2012中,右键类名默认是没有创建单元測试的选项的,得须要设置加入.工具-->自己定义: 然后选择命令-->上下文菜单-->编辑器上下文菜单|代码窗体.然后找到创建单元測试,并将其上下移动到下图所看到的位置: 然后又一次打开VS.在类名上右键就能够看到灰色的创建单元測试,处于禁用状态:

[iOS翻译]《iOS7 by Tutorials》在Xcode 5里使用单元測试(上)

简单介绍: 单元測试是软件开发的一个重要方面.毕竟,单元測试能够帮你找到bug和崩溃原因,而程序崩溃是Apple在审查时拒绝app上架的首要原因. 单元測试不是万能的,但Apple把它作为开发工具包的一部分,不仅让你创作的APP更稳定,并且提供了一致.有趣的用户体验,这些都是让用户给你五星评价的源泉.iOS7提供了一个升级的单元測试框架.让你在Xcode中执行单元測试更为easy.当你完毕这一章节,你将学会怎样给现有app加入測试--并有可能培养出对编写測试的热爱! /* 本文翻译自<iOS7

单元測试的优点

对于单元測试.我慢慢的用得多起来.前不久.还对这个东西朦朦胧胧,认为非常神奇. 如今,我认为单元測试真是极好的. 好在哪里呢?就是好来就是好! 靠,这又不是某D某主义,得讲理.怎么个好法,要说出理由. 好吧.我认为单元測试能够 1.保证代码质量 2.提高开发效率 比方说,这2天我与还有一位同事共同开发某模块.他搞前端,我写server端.他要调用我的方法. 开发是并行的,我在写方法的时候,他的界面还没好,那怎么确保我的方法正确呢?不可能等他写好界面,写好调用我方法的代码,然后我俩再一起測试吧?

【Android进阶】Junit单元測试环境搭建以及简单有用

单元測试的目的 首先.Junit单元測试要实现的功能,就是用来測试写好的方法是否可以正确的运行,一般多用于对业务方法的測试. 单元測试的环境配置 1.在AndroidManifest清单文件的Application节点下.引入单元測试使用的库 2.在AndroidManifest清单文件与Application节点平行的节点中.加入instrumentation节点 以下是一个完整的配置的代码 <manifest xmlns:android="http://schemas.android.