4 ms·
Macros are surprisingly useful in the unit testing context. Whether or not it's considered good practice, I like to embed my tests within the header files that
by dasmithii 13y ago
Macros are surprisingly useful in the unit testing context. Whether or not it's considered good practice, I like to embed my tests within the header files that they're associated with. With macros and gcc's -D flag in order to generate production and testing builds separately.
I'm new to the world of C, is this typical?
- silentbicycle 13y agoI've seen people do that before, as well as putting the tests in the .c file, guarded by "#if TEST_MODULE_NAME", and exporting a (module_name)_run_tests(void) function. My preference is to have separate test_module_name.c files. Failing that, I would include tests in the module's .c file rather than the header, so that the header can be relatively short and focused on documenting the module's interface, rather than its implementation details. greatest doesn't force any specific style there, by design.
- simias 13y agoIt's fairly typical. The standard "assert" macro behaves exactly that way, it does not generate code if the code is compiled with NDEBUG defined. Of course you shouldn't abuse it but in this instance it's perfectly fine IMHO. This reminds me that in addition to that the linux kernel has a pretty cool feature for debugging called "dynamic debugging" where you can enable and disable "printk" (the kernel's version of printf) messages dynamically from the shell through the debugfs: http://lwn.net/Articles/434833/ http://lwn.net/Articles/434833/