Show HN: Writing modern C unit tests with Criterion | Hacker News Reader

Show HN: Writing modern C unit tests with Criterion

github.com

34 pointsSnaipe13 comments

Developer here.

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 :)

Did you check out Greg Banks' Novaprova?

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.

Very well made nonetheless.

I think he's got OSX running now, but as you say -- it relies on some platform-specific stuff.

Good to see C test frameworks doing some innovative stuff!

Darwin support is functional today, I'm just waiting for the 3.11 Valgrind release, which fixes a bug which is a showstopper for NovaProva.

Why did you rule out using Google Test (https://code.google.com/p/googletest)?

(In case you mulled over using it.)

Google Test requires you to write your tests in C++ rather than C; so there was times I just could not use it.

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?)

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.

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?

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!

Both will be implemented quite soon.

This looks like some good stuff, but browsing through your code, it's honestly pretty opaque macro hell. Why so obfuscated?

Macros are used to handle platform specific details, for the most part. I don't think it's that opaque, but then again I might be biased.

Reply on news.ycombinator.com