On 02/26/04 03:11, Sisyphus wrote:
Randy Kobes wrote:
On Thu, 26 Feb 2004, Sisyphus wrote:
'perl -Mblib t\test1.t' works fine. But is it possible to get 'make test' to automatically run that command (for each and every '.t' file) ?
I've looked a little harder since making the original post. Seems that if the tests are put in a 'test.pl' then 'make test' runs the script as a simple perl script. The following gets executed:
D:\perl\bin\perl.exe "-Iblib\lib" "-Iblib\arch" test.pl
But if the tests are put into '.t' files in a 't' sub-directory, then the tests get run under some sort of cutesy developer innovation. The following gets executed:
D:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', 'blib\arch')" t\alloc, t\arith, ..., etc.
Is there some MM switch I can use to have my '.t' scripts processed by the former command - or do I have to rewrite them so that they are appropriate for processing by the latter command ?
I'm not aware of such a switch, but then, I've not come across a case where the tests had to be modified in order to run under t/. If you just take your original working test.pl (presumably in the top-level directory) and move it to t/test.t, do the tests still work? Is it possible to come up with a very short test that works as a test.pl but fails (or is skipped) as a t/test.t?
Easy to do (now that I've looked a little further):
The following works fine under 'nmake test' as a 'test.pl' in the top level folder:
------------------------- if(1 == 1) {print "f1 ok\n"} else {print "f1 not ok\n"}
if(2 == 2) {print "f2 ok\n"} else {print "f2 not ok\n"} ------------------------
It prints: f1 ok f2 ok
which tells me all I want to know.
Are you not using Test or Test::* modules for your tests? Test::Harness was made to work with a certain format which the Test::* modules adhere to.
But change it to 'test.t' and move it from the top level to the 't' sub-directory, then nmake test produces:
t\aaaa.......... FAILED before any test output arrived
For it to work as a'.t' script you have to rewrite it as something like:
------------------ print "1..2\n";
$n = 1;
if(1 == 1) {print "ok $n\n"} else {print "not ok $n\n"} $n++;
if(2 == 2) {print "ok $n\n"} else {print "not ok $n\n"} $n++; -----------------
Do that and you'll get: t\aaaa..........ok
(You've probably noticed that when there's a 'test.t' file in a 't' sub-directory 'make test' produces different output to 'perl -Mblib t\test.t')
So it turns out that it's not a really big deal to rewrite my test scripts so that they work - I just find it annoying that I have to do that.
Not that it applies to my situation, but I also find it really annoying when running a test suite that reports test 711 of 893 failed - and I have to try and work out just which test that was and what it was testing.
I would much prefer to see test output like: t\aaaa...... f1 ok f2 ok f3 ok f4 ok f5 not ok f6 ok
t\bbbb...... fa ok . .
where f1, f2, etc. are the actual name of the function being tested (and are hard coded). The function called 'f5' has failed so I can simply search aaaa.t for the string 'f5 not ok' and find out exactly where the failure has occurred.
That's much easier than doing a search for 'ok' and clicking on 'find next' 1422 times :-)
So I've never bothered keeping track of the number of tests performed by my 'test.pl' and now it looks like I'll have to suffer a little inconvenience as a result.
Have you tried: 'nmake test TEST_VERBOSE=1' or if it is in a specific file do 'nmake test TEST_FILES=t/test.t TEST_VERBOSE=1'
It still puzzles me a little as to why the 2 scenarios (ie test.pl vs t\test.t) are treated differently.
Cheers, Rob
_______________________________________________ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
