[tap-l] pgTAP

[David E. Wheeler]

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

> As the guy responsible for the test_types thing, I'll say that I have
> since repented and decided that organizing extra tests (named with  
> ".t"
> extensions) under xt/ is probably a better route in the long run.
>
> This might still be true for the pgTAP case.  Perhaps a shebang or
> something allows them to be '.t' files?  The problem with changing  
> file
> extensions and supporting it in only one tool is that various other
> tools don't work.

They're not executables. One needs to know where psql is, plus  
database connectivity information (host, username, password, dbname,  
etc.). So the harness will have to have that knowledge built into it.

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.

> A good first step might be to discuss it on the module-build at perl.org
> list.  Some way to use features from the new harness without breaking
> compatibility would be interesting.  Perhaps that just takes the form
> of enabling the features if TAP::Harness is found.

Yes. I have little doubt that M::B can be bent to my will. The  
question is, can TAP::Harness?

> Or the tap-x list, where shebangs have been discussed before.  There  
> was
> once some form of config file which switched executables based on
> filenames, but I think that got scrapped.  Shebang plugins?  All the
> test has to do is emit TAP, right?

Shebangs? That has the bias of assuming the files are executable, no?

> I suspect the complicated bits come in when you start trying to pass
> options to the executable/interpreter and adding DWIM bits.

Yep.

Best,

David