Re:Show HN: Writing modern C unit tests with Criterion
by GFK_of_xmaspast on Tuesday September 01, 2015 @10:15AM
(#10152436)
I'm having a little trouble imagining a situation where unit tests for a C codebase are appropriate that would be stymied by having to write the tests in C++. (Maybe relying on struct layout?)
Re:Show HN: Writing modern C unit tests with Criterion
by Snaipe on Tuesday September 01, 2015 @11:08AM
(#10152818)
Because C hasn't been a subset of C++ since C99, there are plenty of case where trying to do C in C++ is awkward or just not possible with standard C++:
First, you'd have to wrap your header inclusions in `extern "C"` to disable mangling, then you would have to make sure you static_cast all your pointers where normally `void*` conversions would have done its job.
Furthermore, all interfaces relying on designated initializers and compound literals are broken unless you decide to compile in nonstandard GNU C++.
And there are more incompatibilities, such as using `static` or `const` in array parameter declarations or using VLA in macros which are not recognized by C++.
It's all about using the right tool for the right job, ultimately.
Re:Show HN: Writing modern C unit tests with Criterion
by Snaipe on Monday August 31, 2015 @06:55PM
(#10149620)
Actually, I didn't know about it until now! The project uses a similar approach to mine, by parsing the DIE tree produced by dwarf, which means that it won't work if you're not compiling with -g.
It also uses some very platform specific stuff, so windows & os x are out, too.
Re:Show HN: Writing modern C unit tests with Criterion
by lsiebert on Monday August 31, 2015 @06:42PM
(#10149573)
personally I use Glib test (https://developer.gnome.org/glib/stable/glib-Testing.html) for c testing, but I'll check this out. Does this let you test what a program sends to stdout and stderr, and let you trap a subprocess to test that the program exits right?
Re:Show HN: Writing modern C unit tests with Criterion
by Snaipe on Monday August 31, 2015 @07:00PM
(#10149646)
By default, if the test raises any signal or exits with anything other than 0, the test fails.
Otherwise, you can't (yet!) test if the code exits with a specific value nor simply redirect input/output, but I'll be sure to take these suggestions into account, thanks!
I made this unit testing framework out of frustrations I had (and still have) with other C frameworks like CUnit or Check.
I wanted to make something much more simple, yet as powerful, and I think (and hope) I nailed it pretty much after a few months of work.
If you have any questions or suggestions, feel free to ask :)
(In case you mulled over using it.)
First, you'd have to wrap your header inclusions in `extern "C"` to disable mangling, then you would have to make sure you static_cast all your pointers where normally `void*` conversions would have done its job.
Furthermore, all interfaces relying on designated initializers and compound literals are broken unless you decide to compile in nonstandard GNU C++.
And there are more incompatibilities, such as using `static` or `const` in array parameter declarations or using VLA in macros which are not recognized by C++.
It's all about using the right tool for the right job, ultimately.
It also uses some very platform specific stuff, so windows & os x are out, too.
Very well made nonetheless.
Good to see C test frameworks doing some innovative stuff!
Otherwise, you can't (yet!) test if the code exits with a specific value nor simply redirect input/output, but I'll be sure to take these suggestions into account, thanks!
Both will be implemented quite soon.