3 ms·
Nothing. That's the way I usually test my C code. It has the drawback that one failing test aborts the whole program. The error messages are not the most infor
by pg314 10y ago
Nothing. That's the way I usually test my C code.
It has the drawback that one failing test aborts the whole program. The error messages are not the most informative, but it does the job.
- klodolph 10y agoThis is easy enough to solve on Unix... simply fork() before each test. Just make sure that the master is single-threaded or this won't work.
- gpderetta 10y agoAlso an option is to siglongjmp out of the abort signal handler.
- vortico 10y agoAlthough hacky, assert(test_foo() /* Checks the sanity of Foo */); does the job for the error messages, and replacing abort() with a custom function like `void check(int condition, const char *format, ...);` can make it not abort the program on an error. I prefer the regular assert() though because I want the build to fail by an aborting test program, and all I care is the line number of failure. Another benefit is that abort() will pause gdb in the exact place that it crashed, with the stack intact if you want to inspect it.
- cormacrelf 10y agoYou can also use the comma operator to document your assert()s, if you don't like using comments. assert(("test_foo() should be true", test_foo())); https://en.wikipedia.org/wiki/Comma_operator#Asserts https://en.wikipedia.org/wiki/Comma_operator#Asserts
- gpderetta 10y agoI have used often and also seen in the wild the following form: assert(condition && "message");
- codr4life 10y agoI've found it worthwhile to add a thin facade on top of assert to support out-of-band reporting of errors even if NDEBUG is disabled: https://github.com/codr4life/libc4/blob/master/src/c4/assert.h https://github.com/codr4life/libc4/blob/master/src/c4/assert...