[tap-l] Mad TAP proposal

Andy Armstrong andy at hexten.net
Thu Nov 1 11:20:43 EST 2007


On 1 Nov 2007, at 15:38, Michael Peters wrote:
> Isn't this the problem that SKIP was designed to fix? If it needs to  
> dynamically
> determined if a test should run, isn't the test itself the best  
> place to do
> that? xt tests shouldn't be run unless explicity done so by the  
> runner of the
> tests (a developer) who presumably knows that they are doing.

The feature request that started all this relates to a large test  
suite most of which needs to be skipped if a graphical environment  
isn't available - so presumably it'd involve executing hundreds of  
tests just to find out that they skipped.

> Instead of "something else" telling the harness which tests to run,  
> why not have
> the harness run them all and the individual tests can decide if they  
> don't want
> to go through with it or not. If "something else" tells the harness  
> which tests
> to run, we loose the information about which tests didn't run and why.

Having to run each test to find out it didn't want to run doesn't  
scale well. Having a mechanism to dynamically select subsets of tests  
can only encourage people to write more tests I'd have thought.

If we decide on a set of rules for which xt/* tests are executed under  
which circumstances it also gives us a language in which to express  
those rules - so instead of being hard wired into TAP::Harness we'll  
have a little TSP document that could be used with any TAP parser.

I've also seen a discussion of test ordering and the practice of  
numbering tests to guarantee a ordering recently; ordering and more  
complex dependencies could also be handled by a t/controller.t that  
emits TSP.

> Testing in Perl is really nice and simple and I'm not seeing the  
> benefits or the
> problems being solved with this complexity that can't already be  
> solved using
> something else.


You could presumably have said the same about the idea of TAP based  
testing. You can after all just have a bunch of programs that pass or  
fail and run them from the shell.

I'm being slightly facetious there :)

I agree that parsimony should guide our decisions but I'm not finding  
it hard to think of use cases for TSP.

-- 
Andy Armstrong, Hexten






More information about the tapx-dev mailing list