The examples suggest that maybe the implementation should use “#str” in the macros (i.e. when you want your string to contain the same thing as the expression itself).
MinUnit – A minimal unit testing framework for C (2002)
51–56 of 56 posts
Re: MinUnit – A minimal unit testing framework for C (2002)
#52Earlier quoted context omitted.
I actually implemented a basic unit test framework in C yesterday and started with basic asserts like you point out, however once I got it working I switched to return values not unlike TFA. The obvious problem with assertions in that they kill your test program immediately at the first failure instead of doing additional tests and potentially give a clearer picture of what's broken exactly. They're also not very fle…
I mostly agree with you, but I would like to make something clear. >I'm also tempted to say that if you need to use GDB to figure out where your tests have failed exactly your framework is not particularly user friendly. Am I missing something? #include int main(void) { assert(0); return 0; } When using clang I get a clear message that includes the filename, the line, and the function: assert.bin: assert.c:5: int mai…
My point was that depending on how you structure your tests knowing the location of the assert might not help you, for instance you could have a helper function that would validate something and generate a failure if something goes wrong, in this case knowing that this specific function failed doesn't help much understanding what test specifically failed. My point was that if you need GDB to figure out what exactly failed then you don't have a very user friendly test framework.
Re: MinUnit – A minimal unit testing framework for C (2002)
#53Earlier quoted context omitted.
I actually implemented a basic unit test framework in C yesterday and started with basic asserts like you point out, however once I got it working I switched to return values not unlike TFA. The obvious problem with assertions in that they kill your test program immediately at the first failure instead of doing additional tests and potentially give a clearer picture of what's broken exactly. They're also not very fle…
Assertions don't actually have to kill the program. They send an abort signal, which means you can catch them with a signal handler. I similarly wrote a simple C testing framework for a little project I was working on, based on assertions. The framework uses signal handlers for aborts and segfaults, and then setjmp/longjmp to handle resuming the test suite at the next test case. This has the particularly nice effect…
I concede that being able to handle segfaults as test failure is a very nice feature, however dealing with signal handlers is a bit more involved that simply using return values and I believe that it might cause portability issues (does it work on Windows for instance?).
I agree that for a decent test framework it might be the best approach but I think at this point we're no longer talking about "a minimal unit testing framework" which was the point of TFA.
Re: MinUnit – A minimal unit testing framework for C (2002)
#54Earlier quoted context omitted.
I mostly agree with you, but I would like to make something clear. >I'm also tempted to say that if you need to use GDB to figure out where your tests have failed exactly your framework is not particularly user friendly. Am I missing something? #include int main(void) { assert(0); return 0; } When using clang I get a clear message that includes the filename, the line, and the function: assert.bin: assert.c:5: int mai…
My point was that depending on how you structure your tests knowing the location of the assert might not help you, for instance you could have a helper function that would validate something and generate a failure if something goes wrong, in this case knowing that this specific function failed doesn't help much understanding what test specifically failed. My point was that if you need GDB to figure out what exactly f…
Oh, I see now. Yeah, trying to make assert output a dynamically constructed message does seem like a PITA.
Re: MinUnit – A minimal unit testing framework for C (2002)
#55One thing I'm pretty doctrinaire about when it comes to this sort of thing is printing out more than just a simple message. Quite often, this makes the problem obvious with no need for deeper investigation. To do this I have a bunch of macros like this: /* check A and B are equal. */ #define EQ_II(A,B,M) (CheckEQII((A),(B),M,#A,#B,__FILE__,__LINE__)) You use it like this: EQ_II(i,3,"blah blah blah"); CheckEQII looks…
> pretty doctrinaire about
And that is the problem.
I have met teams that have gone into analysis paralysis about which unit test framework to use.
I have met teams where one of the impediments to unit testing was "we don't have time to learn something that complicated, we don't understand why all this stuff is necessary".
Answer:
It isn't necessary. Get off your ass and start unit testing with the simplist framework possible.
It's more important, way way more important to just do it than fuss about the framework.
Like TFA.
Once you have actually done that for awhile, someone will say, "Wouldn't it be nice if..."
And _that's_ the time to introduce a framework. Or grow what you have.
On a C project I elected to grow, the nice thing about it is test setup and teardown? It's exactly the same thing as process set up and teardown.
So valgrind will tell you _exactly_ if anything leaked or was uninitialized!
Re: MinUnit – A minimal unit testing framework for C (2002)
#56One thing I'm pretty doctrinaire about when it comes to this sort of thing is printing out more than just a simple message. Quite often, this makes the problem obvious with no need for deeper investigation. To do this I have a bunch of macros like this: /* check A and B are equal. */ #define EQ_II(A,B,M) (CheckEQII((A),(B),M,#A,#B,__FILE__,__LINE__)) You use it like this: EQ_II(i,3,"blah blah blah"); CheckEQII looks…
> pretty doctrinaire about And that is the problem. I have met teams that have gone into analysis paralysis about which unit test framework to use. I have met teams where one of the impediments to unit testing was "we don't have time to learn something that complicated, we don't understand why all this stuff is necessary". Answer: It isn't necessary. Get off your ass and start unit testing with the simplist framework…
Oops, missed this at the time. Rant on... though only for posterity.
There's various reasons why one might be doctrinaire about stuff. One common reason: you're an arsehole. Another one: you're an engineer, and this was what you were trained to do. A bonus third: you had it beaten into you by bitter experience.
Me? Well, I will say that I'm not clever enough to be an engineer.