3

How would one go about testing a whole program? So far, the only things I can think of are:

I could compile the binary and run a test suite on that but that would require a system independent way to call it in C, which is a nightmare based on other questions. I could probably figure out Boost.Process, but Boost isn't currently a dependency so I'd rather not add it just for testing.

Or, using some preprocessor stuff like below (untested), I might be able to rename the main function, make it defined in a header file, and include that in the test suite.

#ifdef TEST_MAIN
#include "progname.h"
int main_test(...){
#else
int main(...){
#endif

Is this necessary or is there a more obvious way to go about this? If it matters, I'm using CMake and Check.

Community
  • 1
  • 1

1 Answers1

1

Stop thinking in terms of in-process test harnesses, you're just asking for trouble.

Instead, tell your build system to use an out-of-process method, such as TAP from perl. TAP is an interface, but the default implementation of the harness is prove(1).

TAP operates on any sort of executable, including shell scripts, perl scripts, and just-compiled binaries. Most likely you would need to write some sort of shell (or other language) script around your main executable. It's perfectly okay to require some shell (e.g. MinGW's) for your testsuite, it won't affect your program's runtime dependencies.

...

That said, you could just make main a one-line wrapper around real_main. No preprocessor needed. But beware that there are a lot of global variables in the C library even if your own code is clean.

o11c
  • 15,265
  • 4
  • 50
  • 75
  • Where do the global variables come into play in this? –  Oct 25 '14 at 03:18
  • @JasonLefler It's impossible to write meaningful tests in the presence of global variables. The best you can do is *try* to reset every global variable to a known state between every single test, but realistically you'll never catch them all, and also that breaks parallel testing. – o11c Oct 25 '14 at 03:21