[tap-l] pgTAP

[Eric Wilhelm]

# from David E. Wheeler
# on Sunday 15 June 2008 08:34:

>On Jun 14, 2008, at 14:37, Eric Wilhelm wrote:

>What I imagined was something like this:
>
>TAP::Harness->new({
>     verbosity => $opts->{verbose} || $ENV{TEST_VERBOSE},
>     timer     => $opts->{timer},
>     color     => $opts->{color},
>     exec      => {
>        '[.]t$' => 'perl',
>        '[.]s$' => [qw(psql -U postgres -d try -f)]
>     }
>});
>
>IOW, a way to map file name suffixes to the commands that should
>execute them.

I still think the suffix thing tends to hurt.  In any case, you have to 
find a way to configure the switches for psql from a few packages away 
to make it work with prove.

>>... Shebang plugins?  All the test has to do is emit TAP, right?
>
>Shebangs? That has the bias of assuming the files are executable, no?

No.  It doesn't even need to assume that the platform supports shebags.  
(trivia:  perl5 automagically interprets shebangs if given one which 
doesn't contain 'perl' -- Test::Harness 2 (ab)used that feature, but 
this is not the path I suggest because it also passes your perl 
switches to whatever that interpreter is.)

Some languages may not even support a comment on the first line or a 
shebang-compatible comment, etc.

The idea is to inspect the file for shebangs (and shebang-like things 
(or any distinguishing directive/identifier on some line in the file.))  
The harness would then choose the associated executable+switches (or 
Source subclass) to process it.  These would be configured via plugins, 
which might register themselves with a shebang regexp or grep callback.

--Eric
-- 
software:  a hypothetical exercise which happens to compile.
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------