From: nathaniel@...
Date: 2003-01-10T13:01:45+09:00
Subject: Re: Test::Unit fails w/no tests [was: testunit 0.1.6 problems]

Gavin Sinclair [mailto:gsinclair@soyabean.com.au] wrote:

> On Thursday, January 9, 2003, 6:56:44 AM, nathaniel wrote:
> 
> > In general I agree, although I'm trying to figure out how important 
> > the 'strictly' part is. I guess you could think of this failure as 
> > just the default test in TestCase; if there are no other tests, a 
> > default test is run that always fails.
> 
> But still, no uncaught exception was detected.

Right. It should be a failure if it is anything.


> For it to be really clear, the failure needs to be identified 
> by what it is, therefore the message "Failure!!! No tests 
> were specified."

Agreed.


> > I both agree and disagree with the inconvenience of it. Yes, if you 
> > keep around a lot of unused TestCases, it would be somewhat 
> > inconvenient, but I'm not sure that's a practice that ought to be 
> > supported. As an XP'er, I'd say, "YAGNI!" and delete the TestCase as

> > soon as it's empty, knowing that it's cinchy to add back. If I know 
> > that I'm going to add another test to that TestCase in a minute,
then 
> > the failure is a boon, because it keeps me from getting distracted
and 
> > forgetting to add the test.
> 
> OTOH, it's "cinchy" for the user to put a tautological fail 
> case in there.

I absolutely agree. As I just said in ruby-talk:61064, it's really
pretty easy either way; it's just a matter of which class of users have
to do a bit more work: those who want a failure for an empty, or those
who don't.


> One reason for not deleting a TestCase is that if you *do* 
> think you are going to use it soon-ish, then it's a hassle to 
> delete files from a CVS repository and reuse them later.

Right. But is the failure such a bad thing in that case? It's just
reminding you to get back to it.


> Another comment: I like unit testing, but I'm not a confirmed 
> XP'er. In my mind, there's nothing whatsoever wrong with an 
> empty unit test. Just like there's nothing wrong with an 
> empty class/method.  It's a placeholder.  I'd like to see 
> Test::Unit provide for users with a broad range of methodologies.

I guess where I'm coming from is that I'd rather have a unit testing
framework make too much noise as opposed to too little. Those who want
less noise can easily filter it by adding a blank test. But perhaps it
should be the other way around.


> > I guess what I'm saying is that the failure wouldn't hurt my way of 
> > working, and might even help it sometimes. It's not my goal,
however, 
> > to impose my development methodology on others, so it could very
well 
> > be that this ought to go.
> 
> For those reasons, I believe it ought to go.

Well, others have chimed in to say that it's not just an XP thing. So I
think perhaps that's not a good enough argument to get rid of it.


> If opinion is split, perhaps it could be a command line 
> option.  I would generally avoid option proliferation, but I 
> think "--fail-empty-tests" has a nice ring to it :)  I'd 
> probably use it once in a while to look for gaps, but to boil 
> it down to one sentence, I would not use it all the time, because:
> 
>   When I see failures, I want real failures, and I do not want to have
>   to "spoonfeed the compiler" just to avoid them.

I can certainly understand and respect that viewpoint. Not sure if I'll
go with it in the end, but only time will tell.

BTW, thanks for all the feedback. This dialogue has been very helpful to
my thinking on the matter.


Nathaniel

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI