Perl's not the only TAP source

[David E. Wheeler]

On May 30, 2009, at 3:19 PM, Steve Purkis wrote:

> Can people (who aren't me :) try it out and see if it DTRT?  I'd  
> like to test the docs too so I'm not gonna say too much, but to  
> direct it:
>
> 1. try out prove with *.tap  (create it first ;-)

     apropos ~/dev/perl/sourcedetector> perl -Ilib bin/prove ~/Desktop/ 
base.tap
     /Users/david/Desktop/base.tap .. ok
     All tests successful.
     Files=1, Tests=316,  0 wallclock secs ( 0.05 usr +  0.00 sys =   
0.05 CPU)
     Result: PASS

Looks good.

> 2. write a plugin for prove that treats *.1 the same way as *.tap

I see the sample plugin there, but I don't really understand enough to  
do much with it. What method should I implement to intercept file  
names and tell TAP::Harness how to process them?

> 3. try and get a new source of TAP working in a M::B script

Success! I created the attached pgTAP source and the wrote a Build.PL  
as follows:

     my $build = Module::Build->new(
         module_name        => 'MyTapTest',
         license            => 'perl',
         test_file_exts     => [qw(.t .s)],
         use_tap_harness    => 1,
         tap_harness_args   => {
             sources => {
                 Perl  => undef,
                 pgTAP => { dbname => 'try', username => 'postgres' }
             }
         },
         build_requires     => {
             'Module::Build' => '0.30',
             'TAP::Harness'  => '3.12',
         },
     );
     $build->create_build_script;

And it worked perfectly, running t/*t as Perl tests and t/*.s as pgTAP  
tests. W00t! The only other thing I might want to do is have a way to  
tell it to run a pgTAP test even if there is no test script in t. I  
can take that to a different thread, though, once this stuff is done.

> And:
> 4. think of ways we can make any of this easier for people.

It needs more documentation. It took me quite a while to figure out  
that I could get at source-specific configuration data in `$args- 
 >{config}`. Data::Dumper helped me out here. I'll likely write up  
detailed docs as I figure how how to write a proper pgTAP source.

>> I'm fine with a mapping of suffixes myself, but as I said,
>> there has been some resistance. ...
>>
>>   http://testanything.org/pipermail/tap-l/2008-June/000238.html
>>
>> But I could see supporting a standard mapping, such as:
>>
>> .pl - Perl
>> .p6 - Perl 6
>> .pasm - Parrot
> ...
>
> $worm_can->open;
>
> I think that's a sensible idea, especially if they're configurable.   
> I actually came to a similar conclusion re: looking @ shebangs..  
> though I've not yet made them available to Source writers it  
> wouldn't be hard to.  Would help disambiguate .sql, for example.   
> And files with no extension (that aren't binary).

Well, .sql files don't have shebang lines. But have I missed something  
here?

> Unfortunately TAP::Parser *always* assumes files are perl scripts  
> unless you use exec.  Winced when I preserved that for backwards  
> compat...

Yeah, exec is the way to go for everything, really.

> If I've done it right, hopefully we've got a good foundation on  
> which to take this a lot further.  The sources I've got so far are  
> pretty basic...  One way or another we'll have to decide what  
> sources to ship by default.

I think it's a great start. Things are already a lot simpler for me,  
once the source is written. I think maybe the source could be even  
simpler; I'll play around with that, too.

> PS: Hope PGCon was good!  if they'd waited a month I mighta made  
> it... :)

PGCon was great, my talk went over really well. More testing!

Best,

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgTAP.pm
Type: text/x-perl-script
Size: 2917 bytes
Desc: not available
Url : http://www.hexten.net/pipermail/tapx-dev/attachments/20090610/71b9795c/attachment-0001.bin 
-------------- next part --------------