Hacker News new | ask | show | jobs
by ant6n 1594 days ago
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.
2 comments

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.
...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.