5 ms·

C unit testing framework in 2 defs: http://www.jera.com/techinfo/jtns/jtn002.html http://www.jera.com/techinfo/jtns/jtn002.html

by abtinf 13y ago

silentbicycle 13y ago
I wrote greatest because minunit doesn't provide any of the infrastructure that nearly every test runner grows eventually, in some ad hoc way. Halting after the first error is just not good enough after projects grow beyond a certain size. Also, being able to run just specific suite(s) or test(s) by name patterns from the command line really speeds up one's workflow. I still wanted something as straightforward to use as minunit, though. Not knocking it. I'd rather use minunit than something that imposed its own architectural opinions on my projects, or consumed resources already in short supply. Also, I make a lot of small C utilities and libraries, and having to define a "project" just to have tests adds a bit too much friction. (I wrote a bit more about that here: http://spin.atomicobject.com/2013/07/31/greatest-c-testing-embedded/ http://spin.atomicobject.com/2013/07/31/greatest-c-testing-e... )
- abtinf 13y ago
  Agreed. I've skimmed the source and it looks like it would be much easier to integrate into a build system as well. I find Minunit helpful because its easy to memorize and dump into a new project for quick testing. Its brevity also seems to help introduce c devs to unit testing.
sigvef 13y ago
Minunit has grown significantly since the initial 2-def version: https://github.com/siu/minunit https://github.com/siu/minunit .
to3m 13y ago
One disadvantage of the macro-based approach - and it looks like greatest suffers from the same problem - which isn't actually that unusual - is the difficulty of setting a breakpoint on the code that fails a test. This comes in handy when a test fails and you'd like to investigate. And due to C's limitations, you will actually have to do this quite often, on a wide range of failures, because the failure messages don't seem to print any details about the values being compared. So you'll need to hit the debugger to find out anything out.
- silentbicycle 13y ago
  I'm been thinking about ways to get around this. I'm using macros for __FILE__ and __LINE__, but it does interfere with breakpoints. One of my open issues is to add an ASSERT_EQ_MEMCMP function that does print out the difference, probably as a hexdump. Similarly, greatest could have something like 'ASSERT_EQ_NUM' for the cases where printing the value is meaningful, and an ASSERT_EQ_STRUCT that takes cmp and print functions. I've been thinking about it for a while, because I want to get it right before I change the API.

C unit testing framework in 2 defs: http://www.jera.com/techinfo/jtns/jtn002.html http://www.jera.com/techinfo/jtns/jtn002.html

by abtinf 13y ago

C unit testing framework in 2 defs: http://www.jera.com/techinfo/jtns/jtn002.html http://www.jera.com/techinfo/jtns/jtn002.html

silentbicycle 13y ago

I wrote greatest because minunit doesn't provide any of the infrastructure that nearly every test runner grows eventually, in some ad hoc way. Halting after the first error is just not good enough after projects grow beyond a certain size. Also, being able to run just specific suite(s) or test(s) by name patterns from the command line really speeds up one's workflow. I still wanted something as straightforward to use as minunit, though. Not knocking it. I'd rather use minunit than something that imposed its own architectural opinions on my projects, or consumed resources already in short supply. Also, I make a lot of small C utilities and libraries, and having to define a "project" just to have tests adds a bit too much friction. (I wrote a bit more about that here: http://spin.atomicobject.com/2013/07/31/greatest-c-testing-embedded/ http://spin.atomicobject.com/2013/07/31/greatest-c-testing-e... )

abtinf 13y ago
Agreed. I've skimmed the source and it looks like it would be much easier to integrate into a build system as well. I find Minunit helpful because its easy to memorize and dump into a new project for quick testing. Its brevity also seems to help introduce c devs to unit testing.

sigvef 13y ago

Minunit has grown significantly since the initial 2-def version: https://github.com/siu/minunit https://github.com/siu/minunit .

to3m 13y ago

One disadvantage of the macro-based approach - and it looks like greatest suffers from the same problem - which isn't actually that unusual - is the difficulty of setting a breakpoint on the code that fails a test. This comes in handy when a test fails and you'd like to investigate. And due to C's limitations, you will actually have to do this quite often, on a wide range of failures, because the failure messages don't seem to print any details about the values being compared. So you'll need to hit the debugger to find out anything out.

silentbicycle 13y ago
I'm been thinking about ways to get around this. I'm using macros for __FILE__ and __LINE__, but it does interfere with breakpoints. One of my open issues is to add an ASSERT_EQ_MEMCMP function that does print out the difference, probably as a hexdump. Similarly, greatest could have something like 'ASSERT_EQ_NUM' for the cases where printing the value is meaningful, and an ASSERT_EQ_STRUCT that takes cmp and print functions. I've been thinking about it for a while, because I want to get it right before I change the API.