blob: d0c636ff7626e3359661d0d8a027157b404e7ed5 (
plain) (
blame)
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
|
.Dd December 21, 2018
.Dt TESTING-C 7
.Os "Causal Agency"
.
.Sh NAME
.Nm Testing C
.Nd a simple unit testing setup
.
.Sh DESCRIPTION
This is a simple approach
to unit testing in C
that I've used in a couple projects.
At the bottom of a C file
with some code I want to test,
I add:
.
.Bd -literal -offset indent
#ifdef TEST
#include <assert.h>
int main(void) {
assert(...);
assert(...);
}
#endif
.Ed
.
.Pp
This file normally produces a
.Pa .o
to be linked into the main binary.
For testing,
I produce separate binaries
and run them with
.Xr make 1 :
.
.Bd -literal -offset indent
TESTS = foo.t bar.t
\&.SUFFIXES: .t
\&.c.t:
$(CC) $(CFLAGS) -DTEST $(LDFLAGS) $< $(LDLIBS) -o $@
test: $(TESTS)
set -e; $(TESTS:%=./%;)
.Ed
.
.Pp
Note that the test binaries
aren't linked with the rest of the code,
so there is potential for simple stubbing or mocking.
.
.Pp
To get the best output
from C's simple
.Xr assert 3 ,
it's best to assert the result
of a helper function
which takes the expected output
and the test input,
rather than calling
.Xr assert 3
inside the helper function.
This way,
the message printed by the assert failure
contains a useful line number
and the expected output
rather than just variable names.
.
.Sh AUTHORS
.An Mt june@causal.agency
|