Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Poor man unit testing

Reply
Thread Tools

Poor man unit testing

 
 
Andrea Crotti
Guest
Posts: n/a
 
      07-22-2010
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
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      07-22-2010
On 07/22/10 08:34 PM, Andrea Crotti wrote:
> 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.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      07-22-2010
On Jul 22, 11:34*am, Andrea Crotti <(E-Mail Removed)> wrote:
>
> 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.

 
Reply With Quote
 
Andrea Crotti
Guest
Posts: n/a
 
      07-22-2010
>
> 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...
 
Reply With Quote
 
Andrea Crotti
Guest
Posts: n/a
 
      07-22-2010
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---
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-24-2010
On 7/22/2010 7:25 AM, Andrea Crotti wrote:
>>
>> 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?


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.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      07-29-2010
On Sat, 2010-07-24, Eric Sosman wrote:
> On 7/22/2010 7:25 AM, Andrea Crotti wrote:
>>>
>>> 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?

>
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Andrea Crotti
Guest
Posts: n/a
 
      07-29-2010

> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
unit-profiling, similar to unit-testing Ulrich Eckhardt Python 6 11-18-2011 02:00 AM
Unit testing errors (testing the platform module) John Maclean Python 1 04-13-2010 02:11 PM
Test::Unit - Ruby Unit Testing Framework Questions Bill Mosteller Ruby 0 10-22-2009 02:02 PM
Poor, poor P&S owner learns too late... Rich Digital Photography 66 06-11-2009 04:48 AM
Poor reception, poor connection, and dropped signal =?Utf-8?B?dW51c3VhbHBzeWNobw==?= Wireless Networking 2 06-07-2006 12:54 AM



Advertisments