I'm just catching the tail end of this thread, so I hope I'm understanding.
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\.. 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\..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\..
f1ok
f2ok
f3ok
f4ok
f5not ok
f6ok
t\..
faok
.
.
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 .t for the string 'f5not 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
