How to retain function test code?

[C-turtle]

One C program writing practice is this:

You write a function:
myfunction(){
// a lot of code
}

They you write a main with code to test myfunction:

main(int argc, char** argv){
// some myfunction() test and demo code
}

Then you progress to other functions and discard the main(){}

Other than simply commenting out the main() with the test code for my
function
is there any elegant way to keep it and disable it and enable it with
minimal work?
and minimal ugliness cluttering the file?

Is there an evolved practice and experience on this that some of the kind
souls on this newsgroup would like to share?

thanks
C-turtle



-=-

 

[Ben Pfaff]

You write a function:
myfunction(){
// a lot of code
}

They you write a main with code to test myfunction:

main(int argc, char** argv){
// some myfunction() test and demo code
}

Then you progress to other functions and discard the main(){}

Other than simply commenting out the main() with the test code
for my function is there any elegant way to keep it and disable
it and enable it with minimal work? and minimal ugliness
cluttering the file?

You can use something like "#ifndef STANDALONE_TEST...#endif" or
you can put the test code in a separate source file.

 

[Eric Sosman]

One C program writing practice is this:

You write a function:
myfunction(){
// a lot of code
}

They you write a main with code to test myfunction:

main(int argc, char** argv){
// some myfunction() test and demo code
}

Then you progress to other functions and discard the main(){}

Other than simply commenting out the main() with the test code for my
function
is there any elegant way to keep it and disable it and enable it with
minimal work?
and minimal ugliness cluttering the file?

Is there an evolved practice and experience on this that some of the kind
souls on this newsgroup would like to share?

Two methods seem to be in common use:

- Put the tested code and the testing code in the same
source file, but surround the latter with something
like `#ifdef TESTING' ... `#endif'. Most compilers
provide a way to define or undefine a macro like
TESTING without needing to edit the source file;
even if your compiler doesn't do so you can limit
the amount of editing by placing the (non)definition
in a "testing.h" header file #include'd by all sources.

- Put the tested and testing code in different source
files, and only compile and run the latter when you
need to. IMHO this is usually the better solution,
because the tested code is presumably intended to be
invoked from separately-compiled sources anyhow: test
your code in the way you intend to use it. Also, this
approach generalizes to larger "integrated" frameworks,
where a single test program may exercise several
different separately-compiled testees.

 

[Mike Wahler]

One C program writing practice is this:

You write a function:
myfunction(){
// a lot of code
}

They you write a main with code to test myfunction:

main(int argc, char** argv){
// some myfunction() test and demo code
}

Then you progress to other functions and discard the main(){}

Other than simply commenting out the main() with the test code for my
function
is there any elegant way to keep it and disable it and enable it with
minimal work?
and minimal ugliness cluttering the file?

Is there an evolved practice and experience on this that some of the kind
souls on this newsgroup would like to share?

thanks
C-turtle



-=-

Here's how I do it:

/ (1) library_code.c */
void foo()
{
/* etc */
}
/* etc /


/* (2) test_library.c */
void test_foo()
{
/* set up test conditions */
foo();
/* analyze results */
}
/* etc */



/* (3)application.c */
int main()
{
foo();
return 0;
}

test_library.c + library_code.c ====>> testappliation

application.c + library_code.c ====>> application

'testapplication' and 'application' are separate executables.

* Any of (1), (2), and (3) can be broken down into
smaller modules as deemed appropriate.

-Mike

 

[Emmanuel Delahaye]

- Put the tested and testing code in different source
files, and only compile and run the latter when you
need to. IMHO this is usually the better solution,
because the tested code is presumably intended to be
invoked from separately-compiled sources anyhow: test
your code in the way you intend to use it. Also, this
approach generalizes to larger "integrated" frameworks,
where a single test program may exercise several
different separately-compiled testees.

100% agreed. It's my way too.