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.
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.
> 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.
2 comments
[ 4.8 ms ] story [ 13.2 ms ] threadhttps://github.com/mity/cutest 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/n...
Here's a few example test cases: https://github.com/rikusalminen/libkepler/blob/master/test/k...
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.
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.