Poor man unit testing

Discussion in 'C Programming' started by Andrea Crotti, Jul 22, 2010.

  1. 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
    Andrea Crotti, Jul 22, 2010
    #1
    1. Advertising

  2. Andrea Crotti

    Ian Collins Guest

    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
    Ian Collins, Jul 22, 2010
    #2
    1. Advertising

  3. On Jul 22, 11:34 am, Andrea Crotti <> 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.
    Malcolm McLean, Jul 22, 2010
    #3
  4. >
    > 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, Jul 22, 2010
    #4
  5. 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---
    Andrea Crotti, Jul 22, 2010
    #5
  6. Andrea Crotti

    Eric Sosman Guest

    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
    lid
    Eric Sosman, Jul 24, 2010
    #6
  7. Andrea Crotti

    Jorgen Grahn Guest

    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 .
    Jorgen Grahn, Jul 29, 2010
    #7

  8. > 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.
    Andrea Crotti, Jul 29, 2010
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    9
    Views:
    491
    Benji
    Nov 23, 2005
  2. qvx
    Replies:
    7
    Views:
    429
  3. pete
    Replies:
    12
    Views:
    711
    Stephen Sprunk
    Dec 27, 2010
  4. Jaap Karssenberg

    conflict between man perlipc and man perlfunc !?

    Jaap Karssenberg, Jan 9, 2004, in forum: Perl Misc
    Replies:
    0
    Views:
    143
    Jaap Karssenberg
    Jan 9, 2004
  5. Replies:
    21
    Views:
    232
    Martijn Lievaart
    Mar 8, 2010
Loading...

Share This Page