Is there a better way to organize my module tests that avoids an explosion of new source files?
Posted
by
luser droog
on Programmers
See other posts from Programmers
or by luser droog
Published on 2013-09-19T20:55:37Z
Indexed on
2013/10/20
10:14 UTC
Read the original article
Hit count: 193
I've got a neat (so I thought) way of having each of my modules produce a unit-test executable if compiled with the -DTESTMODULE
flag. This flag guards a main()
function that can access all static data and functions in the module, without #including a C file.
From the README:
-- Modules --
The various modules were written and tested separately before being
coupled together to achieve the necessary basic functionality.
Each module retains its unit-test, its main() function, guarded
by #ifdef TESTMODULE. `make test` will compile and execute all the
unit tests, producing copious output, but importantly exitting with
an appropriate success or failure code, so the `make test` command will
fail if any of the tests fail.
Module TOC
__________
test obj src header structures CONSTANTS
---- --- --- --- --------------------
m m.o m.c m.h mfile mtab TABSZ
s s.o s.c s.h stack STACKSEGSZ
v v.o v.c v.h saverec_
f.o f.c f.h file
ob ob.o ob.c ob.h object
ar ar.o ar.c ar.h array
st st.o st.c st.h string
di di.o di.c di.h dichead dictionary
nm nm.o nm.c nm.h name
gc gc.o gc.c gc.h garbage collector
itp itp.c itp.h context
osunix.o osunix.c osunix.h unix-dependent functions
It's compile by a tricky bit of makefile,
m:m.c ob.h ob.o err.o $(CORE) itp.o $(OP)
cc $(CFLAGS) -DTESTMODULE $(LDLIBS) -o $@ $< err.o ob.o s.o ar.o st.o v.o di.o gc.o nm.o itp.o $(OP) f.o
where the module is compiled with its own C file plus every other object file except itself.
But it's creating difficulties for the kindly programmer who offered to write the Autotools files for me. So the obvious way to make it "less weird" would be to bust-out all the main
functions into separate source files. But, but ... Do I gotta?
© Programmers or respective owner