1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Introduction
------------
In DHCP, a unit test exercises a particular piece of code in
isolation. There is a separate unit test per module or API. Each unit
test lives in a directory beneath the code it is designed to exercise.
So, we have:
client/tests/
common/tests/
dhcpctl/tests/
And so on.
Ideally each function would be invoked with every possible type of
input, and each branch of every function would be checked. In practice
we try to be a bit more pragmatic, and target the most basic
operations, as well tricky code, and areas we have seen bugs in the
past.
Running Unit Tests
------------------
In order to run the unit tests for DHCP, use:
$ make check
This will run all of the unit tests.
You can run a single test by going to the appropriate test directory
and invoking the test directly:
$ cd common/tests
$ make test_alloc
$ ./test_alloc
There are also a number of options that you can use when running a
test. To see these, use the "-u" flag on the program.
Adding a New Unit Test
----------------------
To add an additional test to an existing test program, you must create
a function for the new test in the C source file:
static void
mynewtest(void) {
static const char *test_desc = "describe the test";
t_assert("mynewtest", 1, T_REQUIRED, test_desc);
/* ... test code ... */
t_result(T_PASS);
}
Then add this function to the T_testlist[] array in the file:
testspec_t T_testlist[] = {
...
{ mynewtest, "some new test" },
{ NULL, NULL }
};
Then you should be able to compile and run your new test.
Adding a New Unit Test Program
------------------------------
To add a new program, such as when a new module is added, you can copy
the "unit_test_sample.c" file (in this directory) to a new name, add
the new file as a target in Makefile.am, and begin adding tests. Do
not forget to add it to CVS via "cvs add".
If there is no "tests" directory for a given subdirectory, then one
must be created. This can be done by:
1. Creating the directory:
$ mkdir $subdir/tests
$ cvs add tests
2. Adding the subdirectory to the build system:
Add to $subdir/Makefile.am:
SUBDIRS = tests
Add to the AC_OUTPUT macro in configure.ac:
$subdir/tests/Makefile
3. Create a Makefile.am in the new directory, something like this:
AM_CPPFLAGS = -I../..
check_PROGRAMS = test_foo
TESTS = test_foo
test_foo_SOURCES = test_foo.c
test_foo_LDADD = ../../tests/libt_api.a # plus others...
See existing Makefile.am for examples, and the Automake documentation:
http://www.gnu.org/software/automake/manual/html_node/Tests.html
Support Functions
-----------------
Here are a few of the most useful functions defined in t_api that you
can use in testing:
void
t_assert(const char *component, int anum, int class,
const char *what, ...);
The name of this function is slightly misleading. It
actually just prints out an error message in the test
output.
void
t_info(const char *format, ...);
Prints out a message in the test output. You should
include "\n" at the end.
void
t_result(int result);
Prints out the result in the test output. You should
use one of the constants for this:
T_PASS
T_FAIL
T_UNRESOLVED
T_UNSUPPORTED
T_UNTESTED
T_THREADONLY
Additional Testing
------------------
Other static or runtime testing is always an option. For instance, you
can use valgrind to check for memory leaks.
$Id: HOWTO-unit-test,v 1.2 2007-11-16 11:04:12 shane Exp $
|
