

Cheat: A minimal unit testing framework for the C programming language - nkurz
https://github.com/Tuplanolla/cheat

======
exDM69
A while ago I was looking for a minimal unit testing framework for C. I
evaluated these two alternatives:

[https://github.com/mity/cutest](https://github.com/mity/cutest)
[https://github.com/silentbicycle/greatest](https://github.com/silentbicycle/greatest)

They're about 1/5th the size of the Cheat framework. I ended up using
"greatest" because it doesn't do any dynamic allocations (intended for
embedded) and I found that an interesting feature (I also do embedded stuff
every now and then).

The way Cheat works is rather peculiar:

> Imagine a source file including a header file. Then imagine the header file
> including the source file that included it. Now imagine doing that three
> times in a row within the same header file. ...

I would like to know the reasoning behind this. It sure seems clever but what
is the advantage that this provides?

In the end, I wound up writing my own special purpose testing framework
because of the nature of the job at hand. I am writing numerical/scientific
code and the problem suffers from a very well understood and documented loss
of numerical precision (it is about computing the motion of satellites and
planets using Kepler's laws - and the numerical inaccuracy happens near escape
velocity). My testing is perhaps closer to stress testing than unit testing.

Here's my test framework (it's only about 300 LOC):
[https://github.com/rikusalminen/libkepler/blob/master/test/n...](https://github.com/rikusalminen/libkepler/blob/master/test/numtest.h)
[https://github.com/rikusalminen/libkepler/blob/master/test/n...](https://github.com/rikusalminen/libkepler/blob/master/test/numtest.c)

Here's a few example test cases:
[https://github.com/rikusalminen/libkepler/blob/master/test/k...](https://github.com/rikusalminen/libkepler/blob/master/test/kepler_test.c)

The method is 1) create a pseudo random initial setting 2) perform a
calculation in two different ways and verify that they match 3) analyze the
results and verify that laws of physics apply 4) repeat (about 8 million times
by default). My tests use about 15 minutes of CPU time currently, which gives
me reasonable confidence that everything works as intended.

~~~
tordek
> I would like to know the reasoning behind this. It sure seems clever but
> what is the advantage that this provides?

Since C provides very little metaprogramming capabilities, this was the only
way to obtain what I wanted: Most (if not all) other testing
libraries/frameworks require some boilerplate to start testing (namely:
defining your `main` function, which calls all of your tests). Additionally,
every time you write a new test, you must remember to add it to your `main`
function.

I decided that those two things were bothersome enough, so I wrote a proof of
concept that evolved into a large project with tons of useful features beyond
that.

