Thread overview
More expressive assert
Aug 15, 2005
Tony Edgin
Aug 15, 2005
Derek Parnell
Aug 16, 2005
Tony Edgin
Aug 16, 2005
Derek Parnell
Aug 16, 2005
AJG
Aug 16, 2005
Derek Parnell
Aug 16, 2005
AJG
Jan 29, 2006
Yves Jacoby
Aug 18, 2005
Tony Edgin
August 15, 2005
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
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
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
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
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
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
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
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
> 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.