Phlip,
Very nice! I've used C's macro pre-processor to do something like
that for some 20 years.
#ifdef RIGOROUS
#define ASSERT(ex) {if(!(ex))fprintf(stderr,"ex false in %s, line %d\n",__FILE__,__LINE__);}
#else
#define ASSERT(ex)
#endif
The default is NOT to check the assertion, since some take quite a bit
of time. Here are some examples:
ASSERT(-4712 <= year && year != 0)
ASSERT(!(year == 1582 && month == 10 && 4 < day && day < 15))
ASSERT(0 <= newStream->queueNextEmpty && newStream->queueNextEmpty < newStream->queueSize)
ASSERT(streamp->queue[at - size])
ASSERT(filename && *filename)
ASSERT(compare(e1, e2) == result);
ASSERT(0 <= linebufp-linebuf && linebufp-linebuf <= line_width)
Here's comes from the last one when the assertion fails
0 <= linebufp-linebuf && linebufp-linebuf <= line_width false in format.c, line 110
-paul-
···
On Tuesday 29 January 2008 10:29, Phlip wrote:
I have invented a new concept of developer test assertions. This post is a
preview of its features, before I release it for Ruby. Porting it to other
languages is left as an exercise for the reader.assert{ 2.0 }
I don't like the simple assertions - assert_equal, assert_match,
assert_not_nil, etc, in my developer tests. They only exist for
one reason - to print out their values when they fail. And then
they don't even reflect their variable names, either.So I wrote an assertion to replace them. Put whatever you want
into it; it prints out your expression, and all its values.
Essentially like this:x = 43
assert{ x == 42 } --> x == 42
x --> 43deny{ x == 43 } --> x == 43 should not pass
x --> 43