On 04/14/2011 05:47 PM, Steven Schveighoffer wrote:
> On Thu, 14 Apr 2011 11:28:39 -0400, spir <denis.spir@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);

Yes. Actually, I did not mean changing assert specifically, rather having an "asserting func" with 2 arguments, like;
    check(expression, expected_value);
Now, my post was unclear (previous ones on the topic used "check").

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 04/14/2011 06:35 PM, Daniel Gibson wrote:
> Am 14.04.2011 17:47, schrieb Steven Schveighoffer:
>> On Thu, 14 Apr 2011 11:28:39 -0400, spir<denis.spir@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);

The problem is how do /you/ get expr's original expression? In other words, is there a way to do it without compiler magic?
(I think even passing expr as string and using string mixins would not do it, because the string must be constant.)

>> -Steve
>
> Another possibility are named unittests and printing out "running test
> 'foobar' was successful".
> One message for every assert is too verbose IMHO.

There may be a third, intermediate mode. But many times having the list of check result is very helpful to support one's thought, or is just what you need in any case. Wouldn't it be stupid to require you to write one writeln per assertion just because we omitted this verbode mode?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 04/14/2011 06:52 PM, Steven Schveighoffer wrote:
> 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 is precisely why I often have a single unittest block, that controls actual test funcs (which have names :-)

void test1 () {...}
void test2 () {...}
void test3 () {...}
unittest {
    // just uncomment func calls you want to run
//~    test1();
//~    test2();
//~    test3();
}
void main () {}

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 4/14/11 1:26 PM, Steven Schveighoffer wrote:
> On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 4/14/11 12:26 PM, Steven Schveighoffer wrote:
>>> Any particular reason why adding a new trait is more
>>> desirable than modifying assert?
>>
>> Absolutely!
>
> Maybe I worded my question wrong. What I meant was what *is* the
> particular reason.

Already mentioned it - enforce() is a prime example. Any similar facility could make good use the feature.

> And keep in mind, when I say modifying assert, I mean changing the way
> assert compiles, not changing it's usage.

I understand.


Andrei

On 04/14/2011 07:09 PM, Andrei Alexandrescu wrote:
> Applying "let me output something and eye it" at the level of each unit test
> does not scale because it makes it extremely difficult to identify issues once
> one test of many produces unexpected output. There are programs (such as
> "expect") that automate that task. The ultimate goal is to make errors noisy
> and easy to identify.

I do agree. But this point gets very different once:
(1) One can selectively chose which tests to run, thus having only output from one(s) relevant to the issue at hand (eg via named unittests),
(2) one can switch from silent to verbose modes.

In the case of unittests used for regression testing (*), the silent mode would initially just say "there is an error here". Then switching to verbose mode, on relevant tests only, would provide helpful data to solve the issue.
But for me unittests are far to be useful only for regression tests. They are everyday development tools I constantly use: as sample code, to study what code actually does, te debud or improve a piece of code; even if I don't practice TDD at all (rarely use tests as kinf of spec).

I have talked about that already, but the message seems difficult to pass for a reason I do not grok.

Denis

(*) I mean, to check all still works fine after a change on an initially running codebase.
-- 
_________________
vita es estrany
spir.wikidot.com

On Thu, 14 Apr 2011 14:38:32 -0400, spir <denis.spir@gmail.com> wrote:

> On 04/14/2011 06:35 PM, Daniel Gibson wrote:
>> Am 14.04.2011 17:47, schrieb Steven Schveighoffer:
>>> On Thu, 14 Apr 2011 11:28:39 -0400, spir<denis.spir@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);
>
> The problem is how do /you/ get expr's original expression? In other words, is there a way to do it without compiler magic?
> (I think even passing expr as string and using string mixins would not do it, because the string must be constant.)

compiler magic :)  I.e. this proposal requires the compiler to change the way assert is implemented.

-Steve

On Thu, 14 Apr 2011 14:57:44 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 4/14/11 1:26 PM, Steven Schveighoffer wrote:
>> On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 4/14/11 12:26 PM, Steven Schveighoffer wrote:
>>>> Any particular reason why adding a new trait is more
>>>> desirable than modifying assert?
>>>
>>> Absolutely!
>>
>> Maybe I worded my question wrong. What I meant was what *is* the
>> particular reason.
>
> Already mentioned it - enforce() is a prime example. Any similar facility could make good use the feature.

Sure.  However, not modifying assert means all asserts in my code should now be rewritten to myassert, or whatever function is implemented.  The huge benefit of modifying assert is that we don't have to change any existing code.

I'm not saying adding a trait is not desirable, I just think it doesn't get us to the right place on its own.

If I ever get around to hacking the compiler, I certainly will try this to see how well it works.

-Steve

On 04/14/2011 09:10 PM, Steven Schveighoffer wrote:
> On Thu, 14 Apr 2011 14:57:44 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 4/14/11 1:26 PM, Steven Schveighoffer wrote:
>>> On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> On 4/14/11 12:26 PM, Steven Schveighoffer wrote:
>>>>> Any particular reason why adding a new trait is more
>>>>> desirable than modifying assert?
>>>>
>>>> Absolutely!
>>>
>>> Maybe I worded my question wrong. What I meant was what *is* the
>>> particular reason.
>>
>> Already mentioned it - enforce() is a prime example. Any similar facility
>> could make good use the feature.
>
> Sure. However, not modifying assert means all asserts in my code should now be
> rewritten to myassert, or whatever function is implemented. The huge benefit of
> modifying assert is that we don't have to change any existing code.
>
> I'm not saying adding a trait is not desirable, I just think it doesn't get us
> to the right place on its own.
>
> If I ever get around to hacking the compiler, I certainly will try this to see
> how well it works.

A solution may be to carefully craft the new trait-using func's interface so that upgrading can be automatised (rewriting tool for assert calls only); possibly with constraints to make the tool's life easier, like "assertions stands alone on their line".

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 2011-04-14 16:03, Steven Schveighoffer wrote:
> On Wed, 13 Apr 2011 21:04:25 -0400, Adam D. Ruppe
> <destructionator@gmail.com> wrote:
>
>> On the other hand, having output there might be more interesting
>> to look at than "yay the asserts all passed!".
>
> I think this is a good point. Someone playing with a language might type
> in the example, and do:
>
> /home/steves> dmd example.d
> /home/steves> ./example
> /home/steves> (ok... I guess that worked, but I'm not sure what happened)
>
> In other words, there is a benefit to the interaction with the learner.
> In other words, you get to "see it working", rather than only see when
> it fails. You also get a confirmation that the compiler is actually
> building something. For the above code, all one really knows is that the
> compiler made an executable. There's no confirmation that the code being
> run is actually what you typed in.
>
> 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).
>
> -Steve

I agree. For one of my projects I created a simple unit test "framework" that:

* Displays the number of tests
* Doesn't stop the whole run when a single assert fails
* Prints out the failing asserts, if any
* It's possible to add descriptions to the tests

The testing framework in use: http://www.dsource.org/projects/orange/browser/tests/Serializer.d#L249

The actual framework: http://www.dsource.org/projects/orange/browser/orange/test/UnitTester.d

-- 
/Jacob Carlborg

On 2011-04-14 18:48, Andrei Alexandrescu wrote:
> On 4/14/11 9:03 AM, 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).
>
> Could this be achieved within the language?
>
> Andrei

Don't know exactly how he wants it to behave but I have have a look one of my earlier posts:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=134796

-- 
/Jacob Carlborg