Poor man unit testing

[Andrea Crotti]

Hi all, I work on a small but still complex C program, and we would like
to have some automatic unit testing setup.

At the moment we have in many C files an
--8<---------------cut here---------------start------------->8---
#ifdef STANDALONE
main()
.... with asserts

#endif
--8<---------------cut here---------------end--------------->8---

and then we compile accordingly from the Makefile for the testing.

This is of course not so great.

I would like something automatic that
1. if there is a STANDALONE compile it and run it
2. put an entry test in the Makefile and make the others depending on it

The problem is that the include path is quite complex and there are many
flags (not to mention other object files that depend on them).

I've seen also many unit test frameworks but actually they're too
complex for us at the moment..
Thanks for any hints,

Andrea

 

[Ian Collins]

Hi all, I work on a small but still complex C program, and we would like
to have some automatic unit testing setup.

At the moment we have in many C files an
--8<---------------cut here---------------start------------->8---
#ifdef STANDALONE
main()
.... with asserts

#endif
--8<---------------cut here---------------end--------------->8---

and then we compile accordingly from the Makefile for the testing.

This is of course not so great.

I would like something automatic that
1. if there is a STANDALONE compile it and run it
2. put an entry test in the Makefile and make the others depending on it

The problem is that the include path is quite complex and there are many
flags (not to mention other object files that depend on them).

I've seen also many unit test frameworks but actually they're too
complex for us at the moment..
Thanks for any hints,

Bite the bullet!

Even though it is a C++ frame work, googletest is very easy to get up
and running.

 

[Malcolm McLean]

The problem is that the include path is quite complex and there are many
flags (not to mention other object files that depend on them).

So really you're doing white box testing rather than unit testing. You
can't unit test code that depends for its behaviour on other code that
you haven't tested, but you can whitebox test it.

For each C source file rename the function main testxxx, where xxx is
the name of the file. Then have a master test function that calls each
test suite, in alphabetical order. Unless the program is massive you
can maintain this manually. If there are too many source files to keep
track of, it's easy to knock up a perl utility to spit out 'testme.c'.
(I've leave the question of whether testme.c has a testtestme function
or not up to you).

Compile the whole lot, then just have a switch that calls testme. Or
even call testme on every test run.

 

[Andrea Crotti]

Bite the bullet!

Even though it is a C++ frame work, googletest is very easy to get up
and running.

that's very nice thanks, I'll give it a try soon.

But for this project we don't have physical time to set it up, can
someone suggest a dirty (but elegant) trick to do what I asked?

Otherwise I may even use some bash script magic...

 

[Andrea Crotti]

I solved with something like

--8<---------------cut here---------------start------------->8---
#!/bin/bash
set -x
for x in $(grep -l STANDALONE $x *.c)
do
TEST_FILE=tests/test_${x%.c}
$@ -o $TEST_FILE $x
done

for t in tests/test_*
do
echo "runnning $t"
./$t
done
--8<---------------cut here---------------end--------------->8---

now I would like to make it return 0 only if all of them are successful
and then it's perfect (almost).

I call it from the Makefiel
--8<---------------cut here---------------start------------->8---
test: *.c
./test.sh $(CC) $(WARN) $(STD) $(INCLUDE) $(CFLAGS) $(DEBUG) -DSTANDALONE -DDEBUG
--8<---------------cut here---------------end--------------->8---

 

[Eric Sosman]

that's very nice thanks, I'll give it a try soon.

But for this project we don't have physical time to set it up, can
someone suggest a dirty (but elegant) trick to do what I asked?

Have you ever heard the saying "There's never time to do it
right, but there's always time to do it over?"

Also, dirty elegance is a lot like humane torture.

 

[Jorgen Grahn]

Have you ever heard the saying "There's never time to do it
right, but there's always time to do it over?"

Sometimes it's better to improve things in small steps. Going to some
test framework would probably have meant moving the STANDALONE code
out into separate source files, and maybe exposing more of the
translation units under test. Which in turn would mean he'd have to
convince other team members, etc.

I really like when people do smallish cleanup tasks like this one.
Most learn to live with the status quo.

/Jorgen

 

[Andrea Crotti]

Sometimes it's better to improve things in small steps. Going to some
test framework would probably have meant moving the STANDALONE code
out into separate source files, and maybe exposing more of the
translation units under test. Which in turn would mean he'd have to
convince other team members, etc.

I really like when people do smallish cleanup tasks like this one.
Most learn to live with the status quo.

/Jorgen

Yes I totally agree, I like frameworks but I have to arrive to them with
a nice path.
That's why I didn't start to use something like turbogears until I did
almost everything by hand.

Anyway now we just need to create a file like
tun.test.c anywhere
and with make tests it will be compiled and executed automatically.

Is already quite cool and more than enough for now.