Hacker News Reader

Hacker News

Comment by rustybolt | Hacker News Reader

Full thread

rustybolt

Shameless self-plug since I recently made a small header-only C testing "framework":

https://github.com/rubenvannieuwpoort/c_unit_tests

Feels a bit more in line with the spirit of C (small language, few dependencies).

View on HN

This is really nice. I wonder if there is a way to make this work without constructors.

Can possibly be done with a custom section, though not sure that is better and might require fancy compiler flags.

Indeed, I just made a POC with compiler sections: https://github.com/cozzyd/examc

This implementation only works with gcc though probably (it uses the automatic __start_SECTION and __stop_SECTION that gcc generates but clang doesn't seem to... there are likely hacks to make this work anyway though).

In principle, this approach allows interspersing your tests throughout a shared library instead of all in one file (though in that case you wouldn't want the testing function to be called main and you would need a separate driver program for test).

Nice. Now how could I get this to work on a small embedded device compiker (gbdk using lcc), which likely doesn't have that constructor attitude.

...after some thinking, maybe it would be possible to do a manual preprocess using a simple python script that collects all the tests and inserts them in the test main.

One approach is to build test traversal machinery out of function static variables and have every TEST() macro turn into a function that takes a pointer to some state controlling which test to run next.

You don't need malloc if using local variables either, which is helpful when your target doesn't have malloc or when debugging memory problems on targets that do. It's nice to know the test framework cannot be leaking or use-after-free anything.

Interesting. But how would one test "know" about the next one, especially if they are in different compilation units.

Discovery is at runtime. Syntax goes something like MODULE(foo) { DEPENDS(bar); TEST("I like string names") { CHECK(42 == life()); } } where DEPENDS either sends control flow off to bar or onwards towards the test case depending on the value of an argument to the function MODULE created.

Reply on news.ycombinator.com