Forgive me for not making myself clear in the first place. What I'm trying to do is create a Test framework for a server-class product that validates digital certificates using Perl. I've a driver script that reads configuration variables from an XML file using XML::Simple and execute a bunch of tests on the server based on pre-set configuration variables. My effort is to build an optimal, extensible test-suite, whereby I'll develop a reasonably generic framework to which others (developers) can contribute tests in future. This framework will also allow me to execute some tests and skip others based on my requirements. The need to "pass variables" mainly arises because I build relative paths to various directories in my configuration file and the test scripts will need these values based on the tests executed. One approach would be initialize all these values into environment variables in my driver script. But this did not appeal to me as an optimal approach. Can you share your ideas on this approach?
I have written Perl modules, which export specific functions. These functions will be called from my test scripts based on the test-case being executed. I also use standard CPAN-modules such as LWP and OpenCA::OpenSSL in my test-suite. That said, the issue I'm facing is to create atomic test scripts that'll be executed by my driver script based on some configuration file (such as MANIFEST). These atomic scripts will import functions (and variables) from the modules I've created and also from standard CPAN-modules as and when necessary. I am looking for a mechanism whereby I can integrate these test scripts with my driver program. Right now I've this huge driver program where the tests are executed in sequence. To this extent I tried resuing the capability already available in Test::Harness (instead of re-inventing the wheel). But as Wiggins mentioned in an earlier mail, Test::Harness does not allow variables to be "exported" to test scripts. So, I'm trying to find a mechanism to overcome this problem. Hope I gave a better picture. Till now I've been going around in circles and getting frustrated in the process. So, I decided to seek help from Perl experts such as you :) I am trying to find out how I can go about architecting the whole thing. Thanks a lot for your valuable feedback. I am going through the test scripts of LWP too. Best Regds Rajesh Dorairajan -----Original Message----- From: drieux [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 3:54 PM To: begin begin Subject: An Alternative to Test::Harness was Re: external sub routine 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]
