Bryce Harrington wrote:
Default tests - Like probably a lot of perl module writers, I don't
write tests nearly as often as I should, but I have collected a few
simple default tests that I can toss into a new module and reuse
without modification. For example:
http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/00_initialize.t
A similar one is created when creating a distribution with
Module::Starter.
http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/> 01_script_compile.t
http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/zz_dump_config.t
It would seem to be useful if CPAN were to have a couple really basic
tests like this to run for perl modules that haven't created any
tests
themselves.
Might be useful, but you can unfortunately assume very little as you
don't know anything about the distribution. For example,
Test::Distribution (as someone else mentioned it in another mail) is
very useful, but doesn't work in every cases. I had to disable some of
its tests for some of my modules because of the way the distribution
are made.
Beta testing - CPAN tracks intra-module dependencies, and does
automated
testing, but only on released modules. It would seem useful to allow
an author to upload a "beta" version of their module, and then run
the
tests of a dozen or so modules that depend on it. This way, you
would
gain confidence that your next release won't break everyone else's
code (or be able to explain why, if it must.)
Using CPANTS to know what modules depend upon yours and PITA for the
testing subsystem will be a way to test such things.
Obviously, this testing would mostly just benefit core modules, but
you could argue that those are probably the ones most in need of
solid
QA. This could save worry time for the core module authors, allowing
them to focus more of their energy into improvements.
For core modules, there's already a better system: we can send patches
to P5P and ask for test on the smoke boxes. They cover more systems
than CPAN Testers, including commercial Unix like Solaris, HP/UX and
AIX, and even rare systems like OSF and VMS.
I imagine this process could become extremely invaluable for doing
large scale upgrades to bring modules forward into Perl 6. For
instance, if it is decided to switch MakeMaker or other low level
modules, then the ability to programmatically generate patches to
upgrade modules would probably help push authors to upgrade their
modules much faster.
For core modules, there're only two words: backward compatibility.
Micheal Schwern has already expressed several times why he mostly
couldn't add new feature in ExtUtils::MakeMaker: because all the
Makefile.PL that currently exist must continue to work with any new
version of EU::MM, and unfortunately, many use it in strange and
twisted way that could easily be broken by new features.
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
