C language unit testing framework - CUnit

1. Introduction to CUnit

CUnit is a C language unit testing framework written in C language for writing, managing and executing unit test cases.

It is often compiled in the form of a library (static library or dynamic library) for users to test codes for use. When users write programs, they can directly link this static library.

It provides a simple unit testing framework and provides rich assertion statement support for commonly used data types.
CUnit is a combination of a platform-independent framework and various user interfaces. The core framework provides basic support for managing test registries, suites and test cases. The user interface facilitates interacting with the framework to run tests and view results. The organizational structure of CUnit is similar to traditional unit testing frameworks:

2. CUnit installation

CUnit的首页
https://cunit.sourceforge.net/
CUnit 的文档手册地址
https://cunit.sourceforge.net/doc/index.html
中文翻译版
https://blog.csdn.net/benkaoya/article/details/95887879
CUnit 2-1-3下载地址
https://sourceforge.net/projects/cunit/?source=typ_redirect

2.1, installation and configuration - Ubuntu

The packages related to CUnit in the software source are:

libcunit1 libcunit1-dev libcunit1-doc libcunit1-ncurses libcunit1-ncurses-dev

Just use apt-get installthe installer.

2.2. Installation steps

The following is ubuntuthe installation method

tar -jxvf CUnit-2.1-3.tar.bz2
cd CUnit-2.1-3
libtoolize -f -c -i
aclocal
autoconf
autoheader
automake
chmod u+x configure
./configure –prefix=/opt/cunit
make
make install

If sudo apt-get install ncurses-dev cannot solve the problem, follow the centos download method below and
change yum to apt-get install.






The following is centosthe installation method . Download
the CUnit compressed package
https://sourceforge.net/projects/cunit/upload

tar jxvf CUnit-2.1-3.tar.bz2
cd CUnit-2.1-3
yum install -y libtool
mv configure.in configure.ac
aclocal
autoconf
autoheader
automake --add-missing
libtoolize --version
libtoolize --automake --copy --debug --force
automake --add-missing
chmod u+x configure
./configure --prefix=$HOME/local
make
make install

2.3、/usr/bin/ld: cannot find -lcurses

sudo apt-get install ncurses-dev

2.4, centos error

yum install ncurses*
yum -y install glibc-static

2.5. Installation files

After cunit is successfully installed, four folders will be generated: doc, include, lib, and share.

• docThe table of contents is some introductions and instructions for use.
• includeIn the and libdirectory are the header files and library files we need.
• shareThere are files needed in Automated mode in the directory.

3. Introduction to the use of CUnit

3.1. Output method

As shown above, the latter two are mainly interactive interfaces, that is, we can interactively specify parameters and then observe the results. In our specific environment, we usually use the above two interfaces. The first one is to output the results into XML documents, which is convenient for us to generate reports. The second type is only displayed in the standard output after each run, and the test result data cannot be retained.

We can combine the first two outputs, use Basicthe mode when testing ourselves, and use the mode when generating reports Automated.

注：在Curse输出模式下需要联接 -lncurses

3.2. The interface function corresponding to the output mode

Configure the usage Basicmode, and the results of the operation are as follows.

Configure the usage mode, and two files will be generated Automatedafter recompiling and running . If the file name is not set, the default file name will be used.CUnitAutomated-Listing.xmlCUnitAutomated-Results.xml

Put the six files generated by the project CUnitAutomated-Listing.xmland , , and in the CUnitAutomated-Results.xmlCUnit installation directory into a folder, copy them to the window system, and open them with IE browser.CUnit-List.dtdCUnit-List.xslCUnit-Run.dtdCUnit-Run.xsl

Note that if you want to open it with IE browser, neither Google Chrome nor Foxfire browser can be opened correctly.

TestMax-Results.xml

TestMax-Listing.xml

3.3. Writing of test functions

1) First write the test function for the function to be tested.

2) Initialize a Registry.

3) Add a specific Suite to the Registry. You can specify an initialization function and a cleanup function for a Suite.

4) Add the test function to a Suite, so that if the operation of the test function requires some initialization conditions, you can add the code to the initialization function of the Suite, of course, don’t forget to do the corresponding cleaning operation at the end.

5) Use the corresponding interface to output the test results.

6) Finally, clean up the Registry.

3.4, CUnit assertion

CUnit provides a large number of predefined assertions, for almost all C standard types, we can select specific types of parameters that need to be checked.
CUnit defines the assertion as follows:



It can be seen that each type of assertion has two functions FATALand non FATAL. The difference between them is that FATALwhen the non-assertion fails, the program continues to run, and FATALafter the type of assertion fails, the program stops immediately. Usually we use non FATAL.

Note that in our program, we need to outjudge the return value and parameters. When judging whether it is the expected result, we must use assertions printfinstead of using printffunctions such as Assertion, there will be corresponding output items in the result report.

CU_PASS, CU_FAILthese two assertions are special, they just mean that the test program has run to this place. For example, in some test functions, the tested function does not have any return value, etc. In order to prove that this function has been executed, we use the above two functions. They just print a message that they were executed. What's more, they are also exported.

4. Example of using CUnit

#include <signal.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <CUnit/Automated.h>
#include <CUnit/Basic.h>
#include <CUnit/CUnit.h>
#include <CUnit/Console.h>
#include <CUnit/TestDB.h>
#include <assert.h>

int suite_success_init(void){
    
    
    return 0;
}

int suite_success_clean(void){
    
    
    return 0;
}
void test_fun1(void){
    
    
	//测试函数编写
}
void test_fun2(void){
    
    
	//测试函数编写
}
CU_TestInfo test_cases1[] = {
    
    
    {
    
    "test1", test_fun1}, 
    {
    
    "test2", test_fun2},
    CU_TEST_INFO_NULL
};
CU_TestInfo test_cases2[] = {
    
    
    CU_TEST_INFO_NULL
};

CU_SuiteInfo suites[] = {
    
    
    {
    
    "test_cases1:", suite_success_init, suite_success_clean, NULL, NULL, test_cases1},
    {
    
    "test_cases2:", suite_success_init, suite_success_clean, NULL, NULL, test_cases2},
    CU_SUITE_INFO_NULL
};

int main(int argc, char **argv)
{
    
    
    if (CU_initialize_registry()) {
    
    
        fprintf(stderr, " Initialization of Test Registry failed. ");
        exit(EXIT_FAILURE);
    } else {
    
    
		assert(NULL != CU_get_registry());
		assert(!CU_is_test_running());
		if (CUE_SUCCESS != CU_register_suites(suites)) {
    
    
			exit(EXIT_FAILURE);
		}
#if 0
		/**** Automated Mode *****************/
		CU_set_output_filename("TestMax");
		CU_automated_run_tests();
		CU_list_tests_to_file();
#else
		//***** Basice Mode *******************
		CU_basic_set_mode(CU_BRM_VERBOSE);
		CU_basic_run_tests();
#endif
        CU_cleanup_registry();
        return CU_get_error();
    }
    return 0;
}

makefile

all:
	gcc -o test testcase.c -I./include -L./lib -lcunit

According to the centos download method,
the test file is test.c
Makefile

all:
	gcc -o test test.c -I/root/local/include -L/root/local/lib -lcunit -lcurses -static

5. Article source and recommendation

https://blog.csdn.net/cike626/article/details/115268486
https://blog.csdn.net/dongtaintailiang/article/details/118862429
https://huaweicloud.csdn.net/63566c8dd3efff3090b5f3bf.html