An Alternative to Test::Harness was Re: external sub routine

[drieux]

On Friday, Nov 14, 2003, at 13:59 US/Pacific, Rajesh Dorairajan wrote:
[..]
 All I want to do is:

#Create a logger object and log a message using log4perl
#call the function and check the $retval
#if $retval == 1 $logger->info("Test succeded")
#else $logger->warn( "Test failed" )
I've a bunch of such scenarios and I wish to have them in files
like 0.t, 1.t, 2.t....
[..]
 As you can gather I am building a Test suite using
Perl and would like to reuse mechanism used to test perl modules.
In short I want to do something like:
#main.pl

#loop through MANIFEST and read contents into @tests
#runtests from @tests
#0.t
sub test1 {
 my ( $foo ) = shift;
 #initialize logger object
 #call a function from module bar::somebar
 #if success log success
 #if failure log failure
}
The key requirement is that the .t files must capable of acquiring 
values
from main.pl. Is this possible?
This is an interesting approach, forgive me if I need
a bit more information on how you are looking at the
issues of what is being passed into your test harness.
what I gather so far is that you have a directory with
the basics in it
        Makefile.PL
        Somebar.pm
        MANIFEST
        t/
                0.t...
Traditionally when I am doing static code coverage
of that Somebar.pm { one should use at least one
capital in the Module Name, since all lower case
is reserved for pragma. } with the usual
        perl Makefile.PL
        make test
Or when you are talking about testing a perl module
is there some other context I am not seeing here????
I am thinking in terms of having named files in
the t/ that deal with specific code cases, eg:
	t/exception.t

would deal with checking the list of all of the
'exceptions' that it should be handled gracefully.
This way I actually put all of the information in there
that needs to be tested. IF I add a new function/method
and need to check that it will manage all 'n' new exception
cases I merely update that file with 'n' new specific cases.
The files in the t/ directory then become the 'configuration'
information as well as the executable.
I'm not sure that I see what 'value' is added by trying
to make those tests more 'dynamic' by reading from one
file and passing in additional information to the test
that will then test the Module in that directory.
So my problem is less with the idea of using log4perl
to provide additional logging than what exactly this
'testing harness' that is going to be in the 'main.plx'
is suppose to be all about....
Hum... have you looked into say the
libwww-perl where in the t/net section
it has the neat tricks about having a
	require "net/config.pl";

that defines a set of "global" values
that are common to the set of tests.
{ cf <http://search.cpan.org/~gaas/libwww-perl-5.75/> }

This allows the basic Test::Harness
approach, and has a way that common values
are available to the several different test cases.
That might be a strategy that you will find
worth investigating.


ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]