However, it seems "prove" does 1 thing wrong: it doesn't use the Perl executable with which Makefile.PL was executed.

My default Perl is a non-threaded one. Whenever I need to test one of my Thread::xxx modules, I execute the Makefile.PL with a threaded Perl executable. make test then knows to use the threaded Perl for the test. However, prove just uses the default Perl, which causes the test-script to not even compile!

It would seem to me that "prove" would need to find out which Perl executable was used. Or is this not what you had in mind for "prove" ?

Liz

Wow, hadn't thought of that at all. That makes a lot of sense.

Can you please send a request to bug-test-harness at rt.cpan.org, explaining and giving an example?

Thanks, xoxo,
Andy

I really like what you've done with prove. I am wondering, though, why it no longer allows you to include or exclude tests? That's not a function that I often use, but sometimes I just want to be able to do something like this to run all "product" tests:

Then, when I'm satisfied that that the product tests run, I run the full test suite. This is very handy when you have a test suite that takes an hour to run, but you can zip through your product tests in about five minutes.

That's a minor nit, though. It's great work you've put together!

I wasn't sure how I'd implement it. I didn't want to get into having prove do file-glob matching right off. As it is now, you can do

prove $(find . -name '*prove*')
[download]

which gives you the desired result.

xoxo,
Andy

Even ExtUtils::MakeMaker is far from bugfree yet, so the fewer dependencies on it, the better.

Test::Harness is not a testing framework. It's a test reporting framework. Test::More (well, Test::Builder) produces output expected to be interpreted by Test::Harness. Test::Unit has its own test reporting framework, though that's really not the point. It could use Test::Harness.

I don't know what you're on about regarding Makefile.PL as you've described exactly what the default Makefile produced actually does.

As for counting tests, why not just run the test file, make sure everything passes, and then change the no_plan option to plan? If that's too much work, set a dependency for Test::Harness 2.x and set no_plan.

That's why modules such as Test::More allow you to name your tests - it makes finding the offending test much easier. Of course this won't help you with old-style, handmade or bad test suites, but test names are just as variable names - it's up to the author to chose sensible names.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

Also, it looks like line numbers are given with (newer versions of?)Test.pm

t/file..............ok 15/38# Failed test 16 in t/file.t at line 135  
+       
t/file..............ok 19/38# Failed test 20 in t/file.t at line 139  
+       
t/file..............ok 21/38# Failed test 22 in t/file.t at line 141  
+       
t/file..............NOK 22could not append: Permission denied at t/fil
+e.t line 146.
[download]

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

That's why everyone should explain what the test is doing in the comment. Instead of

is( $stooges, 3 );
[download]

use

is( $stooges, 3, "Correct stooge count (in case we get Shemp too)" );
[download]

It's about as self-documenting as you can get.

xoxo,
Andy