On 7/19/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
On 7/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I know we've moved on, but I'm in a completely different time zone, so please
understand...
>
> I, like demerphq, also think that coming up with a name for each and every
test is a good idea.
>
> It shouldn't be hard to think of a description for each and every test.
>
> Just note down why you wrote that test case in the first place.
>
> Don't know why you wrote a test case ? Then delete it, for it serves no known
purpose.
>
> Tests are written for a reason, and that reaons should be part of the test.
Me? I'm just lazy. If the test is pretty obvious by looking at the
code then I'm not going to bother taking the time to repeat myself
with a test description.
How is it pretty obvious which ok() failed when you have fifty ok
tests in a file (with interleaved test setup and teardown
infrastructure) and the only information you have to go on is
not ok 23
????
IMO Thats false lazyness and shouldnt be encouraged.
Also, if the argument is first and undef is allowed then if you
_really_ want you can still not provide a test string. But at least
then its a deliberate action that makesa the test author think to
themselves "hmm, i guess i really should provide a test description".
And you have to think that the description serves multiple purposes:
A) It provides a user encounting a failing test when they try to
install some information as to how important the test is. For instance
if I see a message like "failed to unlink file" i have a pretty good
idea that the premise of the test is faulty as you cant unlink an open
file on win32.
B) It provides a reliable way to quickly find the test that is
failing. This makes it easier for someone who has never seen the code
before to debug. Ive tried to track down bugs in files with no test
descriptions and often ive found the easiest thing is to provide a
test description myself.
C) it gives the user who has encountered a failed test something meaty to report
Note none of these are concerns that affect the AUTHOR of a test file.
They are things that are much more important to somebody trying to
install a package and seeing failing tests, ie a USER.
The great part about descriptions being optional is you can do it your
way, and I can do it my way.
The whole point of this is Quality Assurance. I would have thought
that strongly encouraging higher quality test files while at the same
time allowing people to wimp out is a good thing.
And the current scheme just encourages people to leave off the
description, so id say its less than ideal. IOW the current scheme
makes the description too optional. Reordering the args solves
interface problems and strongly encourages test descriptions.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
