News for hackers. Stuff that matters.
Re:Greatest: C unit testing library in one file by abtinf on Tuesday January 07, 2014 @07:19PM (#7020945)
C unit testing framework in 2 defs:

http://www.jera.com/techinfo/jtns/jtn002.html

Re:Greatest: C unit testing library in one file by silentbicycle on Tuesday January 07, 2014 @07:56PM (#7021055)
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-e... )

Re:Greatest: C unit testing library in one file by abtinf on Tuesday January 07, 2014 @08:08PM (#7021083)
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.

Re:Greatest: C unit testing library in one file by sigvef on Tuesday January 07, 2014 @10:16PM (#7021445)
Minunit has grown significantly since the initial 2-def version: https://github.com/siu/minunit .
Re:Greatest: C unit testing library in one file by to3m on Wednesday January 08, 2014 @04:05AM (#7022493)
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.

Re:Greatest: C unit testing library in one file by silentbicycle on Wednesday January 08, 2014 @07:43AM (#7023124)
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.