On Thu, Apr 07, 2005 at 02:34:21PM -0400, David Golden wrote:
> * Shipping tests is a hint that a developer at least thought about 
> testing.  Counter: It's no guarantee of the quality of testing and can 
> be easily spoofed to raise quality.

This is certainly not why I ship tests, and I've never heard anyone
claim that it's a sensible reason for shipping tests, outside of this
thread.

> * Tests evaluate the success of the distribution against its design 
> goals given a user's unique system and Perl configuration.  Counter: 
> developers should take responsibility for ensuring portability instead 
> of hoping it works unti some user breaks it.

This is exactly why I believe shipping tests with code is a good thing.
I cannot possibly test every perl configuration on every OS. Even if the
team of Benedictine Monks that I employ to do this for could somehow
manage this, unfortunately they are not yet capable of testing it
against /future/ configurations.

Shipping tests with my code protects users from incompatability by
warning them /before/ they install the module, rather than when a user
finally triggers the problem in real code.

The more exhaustive my test suite is, the better this is.

This also makes my life as a developer much better. I don't have to field
lots of bug reports that say nothing more than "I can't get Foo::Bar
version 2.09 to work on Windows". Instead they can tell me "t/wibble.t
fails test 13 on windows saying: 'no such file or directory'". Then,
even without access to that platform, I can probably track down what
the problem is.

Shipping tests is a good thing. The better they are, the better a thing
it is.

Shipping tests that don't actually exercise any functionality of the
code, OTOH, does not share in this mojo. If I have POD for method
frobnitz(), then the POD is there for everyone to enjoy. Shipping a test
that confirms that tells no-one anything, and achieves no purpose, other
than, currently to raise my Kwalitee. Rather, it wastes time for the
poeple installing it, especially as it will recommend that they install
another non-core module (with several other non-core dependencies in
turn).

Kwalitee is only useful if it measures useful things. The presence of a
test file that somewhere mentions the words "Pod::Coverage" is not a
useful thing.

Tony


Reply via email to