optionally verbose assertions

[Steven Schveighoffer]

On Thu, 14 Apr 2011 13:27:32 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

>> On Thu, 14 Apr 2011 12:35:49 -0400, Daniel Gibson  
>> <metalcaedes at gmail.com>
>>
>> wrote:
>> > Am 14.04.2011 17:47, schrieb Steven Schveighoffer:
>> >> On Thu, 14 Apr 2011 11:28:39 -0400, spir <denis.spir at gmail.com>  
>> wrote:
>> >>> On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:
>> >>>> Sometimes, I worry that my unit tests or asserts aren't running.
>> >>>> Every once in
>> >>>> a while, I have to change one to fail to make sure that code is
>> >>>> compiling (this
>> >>>> is especially true when I'm doing version statements or templates).
>> >>>> It would
>> >>>> be nice if there was a -assertprint mode which showed asserts
>> >>>> actually running
>> >>>> (only for the module compiled with that switch, of course).
>> >>>
>> >>> Man, I'm very pleased to read someone else advocating for optionally
>> >>> verbose assertions.
>> >>>
>> >>> This could use 2 arguments instead of a predicate:
>> >>> assert(expressions, value);
>> >>>
>> >>> Example use:
>> >> [snip]
>> >>
>> >> I don't think we can change assert syntax now. What I was looking was
>> >> for something more like:
>> >>
>> >> assert(x == y);
>> >>
>> >> prints out
>> >>
>> >> "asserting x == y: true"
>> >>
>> >> for asserts that pass when you have the 'verbose assert' flag turned
>> >> on. This should be easy to do in the compiler by just translating
>> >>
>> >> assert(expr);
>> >>
>> >> to something like:
>> >>
>> >> auto result = evaluateAssert(expr);
>> >> print("asserting expr: ", result ? "true" : "false");
>> >> assert(result);
>> >>
>> >> -Steve
>> >
>> > Another possibility are named unittests and printing out "running test
>> > 'foobar' was successful".
>> > One message for every assert is too verbose IMHO.
>>
>> I'm thinking of the code examples that have asserts in them. I totally
>> like the idea of code examples in ddoc being compiled as unit tests.  
>> This
>> ensures your examples don't get out of date or are not invalid (as many  
>> of
>> phobos' examples are). Nothing is worse when learning a language to
>> encounter errors or unexpected results from the sanctioned examples.  
>> This
>> means they have to look like unit tests, but also be useful for learning
>> (see my above issue).
>>
>> A compromise might be to be able to name unit tests, and then run a
>> specific unit test by name on execution only. This allows you to ensure  
>> a
>> specific unit test (and specific asserts in that unit test) are running
>> without having to see all the asserts from the other unit tests, but  
>> also
>> allows using asserts for general example code/testing.
>>
>> This also could mean that you could simply directly compile a phobos
>> module with -assertverbose -unittest and do:
>>
>> ./algorithm --run-unit-test std.algorithm.sort_example
>>
>> to see all the asserts working for that example.
>
> I want named unit tests regardless, because then you'd get recognizable
> function names in the stack traces from exceptions that escape unit test
> blocks. Being able to print out which unit test is running or just  
> finished by
> using a particular flag would definitely make some people around here  
> happier
> though (much as it definitely shouldn't be the default behavior).

I agree it should not be the default.

What I'm trying to do is find a solution that makes examples with asserts  
useful for learning (i.e. show that something is happening), and try and  
make it also be useful for unit test debugging.

Obviously, during normal unit tests, you want only errors to print out.

-Steve