Patrick R. Michaud wrote:
On Tue, Sep 02, 2008 at 02:10:39PM +0200, Moritz Lenz wrote:
And then? Spec it? Or ship a prototype Test.pm as "official"?
I think it's good to have a prototype Test.pm that we can point to as
a reference, but I don't think we need to try to designate it as being
"official".
I think we *should* have an official Test.pm, but that it should be
conceptualized in a slightly different way. Or actually I have 2 alternate
proposals:
1. Rather than being a "language extension", Test.pm should formally be
part of the Perl 6 test suite itself, as the result of a refactoring;
basically all tests have some common implementation parts and those have
been refactored into a module, which is Test.pm. So then Test.pm is an
integral part of the test suite itself, and if there is just one official
test suite, then there is just an official Test.pm. Though for convenience
this Test.pm would be installable so that other language extensions could
use it in their tests, though.
2. The Perl 6 language spec itself would specify a basic set of test
routines built-in to the language, in a Test namespace, much as it defines
collections of routines now for such as numbers and arrays and standard
I/O. And so the basic test routines would be formally defined in a
Synopsis document. This shouldn't be onerous as there'd probably be only
about a dozen such routines and given our experience it is probably
reasonable they won't need to change much over time. So how these Test
namespace routines are provided can then vary by the implementation but
they would be standard to users of the language.
Now a common factor to both of my proposals is that this Test.pm is
intentionally kept as simple as possible and contains just the
functionality needed to bootstrap the official Perl 6 test suite; if the
official test suite doesn't use certain features, then they don't exist in
this Test.pm, in general.
There would still be room for third party Test modules, as those would be
richer and provide functionality that would be useful for testing language
extensions / CPAN modules but that aren't needed by the tests for Perl 6
itself.
I should mention that I'm currently pursuing the #2 approach in my Muldis D
language design, where the language spec itself includes a small number of
common routines implementing the TAP protocol over standard I/O, so that
tests written in the language can just use it without having to explicitly
load a Test library like a user-defined library.
An advantage of #2 is that you don't have to think so much about what other
language features your Test.pm uses, since from the users' point of view
they are themselves fundamental features; so implementers could even
bootstrap them using native equivalents or a prelude.
I also don't see the possibility of our "getting it wrong" in the design to
be such a big deal, since the odds are anything we think of now will work
well for many years, as Test.pm/Test::More has been fairly stable already
and meanwhile Perl 6 is versioned now, so we could make an incompatible
change to the Test related language spec in the future, and as long as
users say "use Perl-6.0.0" their code relying on the older/current Test.pm
like interface won't break.
-- Darren Duncan
