On Fri, 11 Feb 2011 14:20:09 -0500, Steve Schveighoffer
<[email protected]> wrote:
It looks as though Jonathan is willing to roll up the code into loops,
so having this debate is academic at this point, but I wanted to respond
to some points.
----- Original Message -----
From:Andrei Alexandrescu <[email protected]>
On Feb 11, 2011, at 2:39 PM, Steve Schveighoffer <[email protected]>
wrote:
> Please please, let's *NOT* make this a standard practice. If a test
fails, I don't want to get a debugger out or start printf debugging *to
find
the unit test*. I want it to tell me where it failed, and focus on
fixing the
problem.
You find the unittest alright. With coming improvements to assert you
will often
see the arguments that caused the trouble.
This will help immensely. Right now, you get a line number. The rule
should be, if a unit test fails, it should give you enough information
to 1) find the failing assert and 2) give you all the information to
understand why the assert failed.
I don't understand how we both derive vastly different conclusions from
the
same extensive eperience with unittests. To me a difficult unittest to
find is a
crashing one; never ever once in my life I had problems figuring out
why an
assert fails in a uniitrst, and worse, I am incapable to imagine such.
foreach(x; someLongArray)
assert(foo(x) > 5);
which x caused the problem? all I get is the line number for the assert.
*sigh*
foreach(x; someLongArray)
assert(foo(x) > 5, text(x) );
Problem solved. Personally, I don't usually add the extra clause to assert
during initial coding; only when they fail do I add something like
text("\nx:\t",x,"\nfoo:\t",foo(x)); or whatever. (Though enforces are a
different story)
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
