Re: Speccing Test.pm?

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

• Speccing Test.pm? by Moritz Lenz
• Re: Speccing Test.pm? by Patrick R. Michaud
• Re: Speccing Test.pm? by Darren Duncan
• Re: Speccing Test.pm? by Geoffrey Broadwell
• Re: Speccing Test.pm? by Mark J. Reed
• Re: Speccing Test.pm? by Patrick R. Michaud
• Re: Speccing Test.pm? by Richard Hainsworth