www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - More expressive assert

reply Tony Edgin <Tony_member pathlink.com> writes:
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
Aug 14 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
Aug 14 2005
parent reply Tony Edgin <Tony_member pathlink.com> writes:
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
Aug 15 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
Aug 15 2005
next sibling parent reply AJG <AJG_member pathlink.com> writes:
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.
Aug 15 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Aug 15 2005
parent AJG <AJG_member pathlink.com> writes:
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.
Aug 15 2005
prev sibling parent Yves Jacoby <kloune gmail.com> writes:
 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.
Jan 29 2006
prev sibling parent Tony Edgin <Tony_member pathlink.com> writes:
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
Aug 17 2005