From: Nathaniel Talbott <nathaniel@...>
Date: 2004-04-16T11:29:32+09:00
Subject: Re: test / unit question:  add "Warnings" to Failures and Errors

On Apr 15, 2004, at 12:22, Bret Pettichord wrote:

> At 10:29 AM 4/15/2004, Its Me wrote:
>> 124 tests, 300 assertions, 0 failures, 0 errors,
>>  26 warnings (15 disabled, 8 skip, 2 todo, 1 other)
>> ..
>
> I argue against this.
>
> It's key to reduce visual clutter when you are running tests. They 
> should be red or green. You shouldn't have to think about what you are 
> seeing. The example above is confusing.
>
> And you shouldn't be using your tests as your to do list. Put them in 
> comments and use Rdoc to extract them. Put them in your eclipse task 
> list. Or build a separate system for tracking them,

Bret, you've pretty well summed up my reaction to this. I've just 
recently been dealing with some pretty mucked up (Java) code, and the 
last thing I'd want to provide those developers with is another way to 
not complete functionality. So I won't propagate such abilities in to 
Test::Unit.

By way of explanation to others, I view things like disabled tests, 
todo tests, and even Eclipse TODO tags as excuses. Now, when I'm 
cranking away at completing a story, I usually have an index card with 
my short list of "excuses" on it. As I run in to things that need to be 
done but would distract me from my current train of thought, I write 
them down. But that list is in such a temporal state that I have to 
deal with those issues before the card disappears. It's OK to make 
excuses to myself for a while, but I'm not going to foist my excuses on 
the next guy that comes along (or even on myself when I look at the 
code next).

If something in the code is important enough to flag, it's important 
enough to deal with now.

I'm sorry if my position seems hard-nosed, but there are other ways of 
flagging these things if that's what you really want to do. They just 
won't show up in the default Test::Unit install.


> In fact i even think the distinction between failures and errors is 
> tedious and unnecessary.

An interesting viewpoint, and one I can certainly understand. However, 
since Test::Unit lets one explicitly assert that exceptions are not 
thrown, I think there is some value in distinguishing between expected 
test failures and unexpected ones. When I'm coding test-first, there's 
a big difference to me between running my tests and getting an error 
(unexpected), and running my tests and getting a failure (expected). So 
I think the distinction will stay. I appreciate you bringing it up, 
though, as it's given me an interesting idea to turn over.

TODO: Have fun coding Ruby...


Nathaniel
Terralien, Inc.

<:((><