View mode: basic / threaded / horizontal-split · Log in · Help
August 15, 2005
More expressive assert
Hi All,

I'm new to D and am thrilled to see a language with built-in support for unit
tests.  

This post is really a feature request.  Currently assert is the way unit test
test -conditions are implemented.  It only takes one parameter, an expression
with must evaluate to a boolean.  It would be nice if it took an optional second
string parameter which would be written to stdout (stderr?) if the first
parameter were false.  This way the programmer could describe what failed.  This
would also aid in the documentation of the unit test.  Does this sound
reasonable?

Cheers,
Tony
August 15, 2005
Re: More expressive assert
On Mon, 15 Aug 2005 00:17:39 +0000 (UTC), Tony Edgin wrote:

> Hi All,
> 
> I'm new to D and am thrilled to see a language with built-in support for unit
> tests.  
> 
> This post is really a feature request.  Currently assert is the way unit test
> test -conditions are implemented.  It only takes one parameter, an expression
> with must evaluate to a boolean.  It would be nice if it took an optional second
> string parameter which would be written to stdout (stderr?) if the first
> parameter were false.  This way the programmer could describe what failed.  This
> would also aid in the documentation of the unit test.  Does this sound
> reasonable?

This has been brought up many times. 

The philosophy behind the current implementation is that asserts will only
be exercised during code testing (and never in production code), and the
people who will see the assert message will also have access to the source
code, and thus can quickly go to the line number displayed in the message
and see the offending assert(), and any comments that the coder has placed
there.

The purpose of asserts is to give a message to the code maintainer, and not
to an end-user. An additional text message would be redundant as the
message can be placed in the code as comments and therefore does not need
to be in the executable.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
15/08/2005 10:24:32 AM
August 16, 2005
Re: More expressive assert
In article <1cj86vgd56eet.hskpm341awka$.dlg@40tude.net>, Derek Parnell says...
>
>On Mon, 15 Aug 2005 00:17:39 +0000 (UTC), Tony Edgin wrote:
>> This post is really a feature request.  Currently assert is the way unit test
>> test -conditions are implemented.  It only takes one parameter, an expression
>> with must evaluate to a boolean.  It would be nice if it took an optional second
>> string parameter which would be written to stdout (stderr?) if the first
>> parameter were false.  This way the programmer could describe what failed.  This
>> would also aid in the documentation of the unit test.  Does this sound
>> reasonable?
>
>This has been brought up many times. 
>
>The philosophy behind the current implementation is that asserts will only
>be exercised during code testing (and never in production code), and the
>people who will see the assert message will also have access to the source
>code, and thus can quickly go to the line number displayed in the message
>and see the offending assert(), and any comments that the coder has placed
>there.
>
>The purpose of asserts is to give a message to the code maintainer, and not
>to an end-user. An additional text message would be redundant as the
>message can be placed in the code as comments and therefore does not need
>to be in the executable.

In my defence, I do understand the difference in purpose between assertions and
exceptions.

Having a text message does still help.  Comments can only tell the code reader
what the code writer thought might happen and nothing about what actually
happens during run-time.  A text message can be generated at
run-time(development not release), so may discribe the state of the test  Think
about it this way.  Currently, a unittest fails with assert(false).  What's the
first thing a code writer probably does?  Inspect the code.  If the reason for
failure isn't obvious, she fires up the debugger.  If the code writer printed
the values of the quantities being compared in the assertion as part of the
message, going to the debugger probably wouldn't have been necessary, or at
least it would give the code writer insight into what may be broken.  This will
even aid in testing the unit test.

Since this suggestion has supposedly been fended off many times, I'm sure a
refutation to my argument has been discussed already.

Cheers,
Tony
August 16, 2005
Re: More expressive assert
On Tue, 16 Aug 2005 02:17:22 +0000 (UTC), Tony Edgin wrote:

> In article <1cj86vgd56eet.hskpm341awka$.dlg@40tude.net>, Derek Parnell says...
>>
>>On Mon, 15 Aug 2005 00:17:39 +0000 (UTC), Tony Edgin wrote:
>>> This post is really a feature request.  Currently assert is the way unit test
>>> test -conditions are implemented.  It only takes one parameter, an expression
>>> with must evaluate to a boolean.  It would be nice if it took an optional second
>>> string parameter which would be written to stdout (stderr?) if the first
>>> parameter were false.  This way the programmer could describe what failed.  This
>>> would also aid in the documentation of the unit test.  Does this sound
>>> reasonable?
>>
>>This has been brought up many times. 
>>
>>The philosophy behind the current implementation is that asserts will only
>>be exercised during code testing (and never in production code), and the
>>people who will see the assert message will also have access to the source
>>code, and thus can quickly go to the line number displayed in the message
>>and see the offending assert(), and any comments that the coder has placed
>>there.
>>
>>The purpose of asserts is to give a message to the code maintainer, and not
>>to an end-user. An additional text message would be redundant as the
>>message can be placed in the code as comments and therefore does not need
>>to be in the executable.
> 
> In my defence, I do understand the difference in purpose between assertions and
> exceptions.
> 
> Having a text message does still help.  Comments can only tell the code reader
> what the code writer thought might happen and nothing about what actually
> happens during run-time.  A text message can be generated at
> run-time(development not release), so may discribe the state of the test  Think
> about it this way.  Currently, a unittest fails with assert(false).  What's the
> first thing a code writer probably does?  Inspect the code.  If the reason for
> failure isn't obvious, she fires up the debugger.  If the code writer printed
> the values of the quantities being compared in the assertion as part of the
> message, going to the debugger probably wouldn't have been necessary, or at
> least it would give the code writer insight into what may be broken.  This will
> even aid in testing the unit test.
> 
> Since this suggestion has supposedly been fended off many times, I'm sure a
> refutation to my argument has been discussed already.

LOL ... I suppose so.

At first, I assumed by 'text message' you were referring to a hard-coded
message rather than one whose content was generated at run time. A
hard-coded message is really just a comment that appears to the user of the
program. However, a generated message that only appears if the assertion is
triggered might be a useful thing, I agree.

Currently you can do this sort of thing to implement your request ...

   assert ( a == b ? true : (writefln("a=%s b=%s", a,b) , false));

Not pretty but does work.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
16/08/2005 12:53:31 PM
August 16, 2005
Re: More expressive assert
Hi,

>At first, I assumed by 'text message' you were referring to a hard-coded
>message rather than one whose content was generated at run time. A
>hard-coded message is really just a comment that appears to the user of the
>program. However, a generated message that only appears if the assertion is
>triggered might be a useful thing, I agree.
>
>Currently you can do this sort of thing to implement your request ...
>    assert ( a == b ? true : (writefln("a=%s b=%s", a,b) , false));
>Not pretty but does work.

C has an nice macro parameter stringification operator for this kind of thing.
So you can do this bit of magic:

| #define string const char * const restrict
| #define ASSERT(e) ((e) || die(__FILE__, __LINE__, \
|     (const String) __FUNCTION__, __DATE__, __TIME__, #e))
|
| static int die(string file, const int line,
|     string function, string date, string time, string expression) {
|     // Print useful message.
|     printf("ASSERTION FAILED: File %s, line %d @ %s() [%s %s]: (%s).",
|         file, line, function, date, time, expression);
| 
|     // Crash and burn.
|     exit(EXIT_FAILURE);
| }

Example usage:

~main.c
| static void main() {
|     ASSERT(42 == 13);
| }

Output (something like):
ASSERTION FAILED: File main.c, line 2 @ main() [Date Time]: (42 == 13). 

I'd love to see D's assert support some (more) of this functionality.
Cheers,
--AJG.
August 16, 2005
Re: More expressive assert
On Tue, 16 Aug 2005 05:19:08 +0000 (UTC), AJG wrote:


[snip]

> I'd love to see D's assert support some (more) of this functionality.

You'll love the new text macro functionality coming to Build real-soon-now
;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
16/08/2005 3:42:06 PM
August 16, 2005
Re: More expressive assert
Howdy!

>> I'd love to see D's assert support some (more) of this functionality.
>You'll love the new text macro functionality coming to Build real-soon-now
>;-)

Darn! Why did I have to read that sentence before going to bed? I will not sleep
tonight after hearing such a good scoop. :D 

*giddy like a kid waiting for ice cream* :)

Cheers!
--AJG.
August 18, 2005
Re: More expressive assert
In article <1592tv33we98x$.gw0od8paeu1p.dlg@40tude.net>, Derek Parnell says...
>
>Currently you can do this sort of thing to implement your request ...
>
>    assert ( a == b ? true : (writefln("a=%s b=%s", a,b) , false));
>
>Not pretty but does work.

Thanks!  That's a good work around.


Cheers,
Tony
January 29, 2006
Re: More expressive assert
> Hi,
> 
>>At first, I assumed by 'text message' you were referring to a hard-coded
>>message rather than one whose content was generated at run time. A
>>hard-coded message is really just a comment that appears to the user of the
>>program. However, a generated message that only appears if the assertion is
>>triggered might be a useful thing, I agree.
>>
>>Currently you can do this sort of thing to implement your request ...
>>    assert ( a == b ? true : (writefln("a=%s b=%s", a,b) , false));
>>Not pretty but does work.
> 
> C has an nice macro parameter stringification operator for this kind of thing.
> So you can do this bit of magic:
> 
> | #define string const char * const restrict
> | #define ASSERT(e) ((e) || die(__FILE__, __LINE__, \
> |     (const String) __FUNCTION__, __DATE__, __TIME__, #e))
> |
> | static int die(string file, const int line,
> |     string function, string date, string time, string expression) {
> |     // Print useful message.
> |     printf("ASSERTION FAILED: File %s, line %d @ %s() [%s %s]: (%s).",
> |         file, line, function, date, time, expression);
> | 
> |     // Crash and burn.
> |     exit(EXIT_FAILURE);
> | }
> 
> Example usage:
> 
> ~main.c
> | static void main() {
> |     ASSERT(42 == 13);
> | }
> 
> Output (something like):
> ASSERTION FAILED: File main.c, line 2 @ main() [Date Time]: (42 == 13). 
> 
> I'd love to see D's assert support some (more) of this functionality.
> Cheers,
> --AJG.

Hi,

This would be especially helpful in the in{} or out{} block. So one
wouldn't need each time to check the source for which assert failed, but
simply read the message, for example 

ASSERTION FAILED: File sort.d, line 2 @ quickSort() [Date Time]: (elements
!= null).

Like for example in Eiffel, where each assert in the pre- and
post-conditions is associated with a keyword, which is reported later.
Top | Discussion index | About this forum | D home