On Monday, Nov 17, 2003, at 00:27 US/Pacific, Rajesh Dorairajan wrote:
Forgive me for not making myself clear in the first place.
forgive me for having to defer a response, But this is a really interesting problem and still requires a bit of thinking.
What I'm trying to do is create a Test framework for a server-class product that validates digital certificates using Perl.
Not a bad idea.
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.
Oh not simple, but ultimately a reasonablish approach. What concerns me here is whether
there needs to be more XML or less
a point I will address later on.
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?
The idea of passing them through the environment is very UGLY.
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.
{ note: I was actually afraid we were off on this adventure... }
I think you may actually have a couple of core 'design issues' that you may want to think through here. You might want to step back and review some of your assumptions. Similarly you might want to look at the 'jam project', cf <http://www.perforce.com/jam/jam.html> which is written, unfortunately in 'c' - but it may help your thinking, the idea here is to create the 'input' that will be used by Make without having the coder understand all of the arcanea Make, hence it is a two step process
jam
makeYou may want to think in a similar manner as to which part of the problem your Generic Test Harness is really trying to solve.
I was involved with 'jel' which was a perl based variation of
the jam. That project turned out to have about 15 or so Perl Modules
in the "Project" namespace. { oh dear, I still have some of
that code, which is the giggler of answering this... 8-) }
our 'jel' of course was essentially a simple piece of code,
in of and by it self that basically did:my $result = eval "use lib '.top'; require './Jelfile.pm';";
Everything Before and after that was the usual sorts of
die "$prog error: No Jelfile.pm in $pwd.\n" unless (-f 'Jelfile.pm');and what did we get for $result, and the various switches based upon OS specific
if ($Config{'osname'} ne 'MSWin32') {...}
The Money Maker was turning non-perl coders into, perl coders without TELLING THEM that was what was happening, since they merely had to create a 'Jelfile.pm' that would use the appropriate perl module call outs, and then invoke the right types of methods with the sorts of things one needs to create a real Makefile with all the required smack in it.
So if you thought of the problem in the form of say
corp_name_test_harness - a simpler driver script
{ note my presumption is that one would grow this out
with Getopt::Long to take alternative config information
and/or additional stuff. }as being little more than an fancy wrapper that does an 'eval' with some appropriate tests for
a. the xml_configfile.conf - the default xml_config file name
b. the corp_test_case.pm - the default "thing to be eval'ed"then what you wind up getting into is a slightly more maintainable strategy, i think, where all you have to do is worry about the name space issues. So for you
sub test1 {....}
if that is merely a 'method' in say
Dtk::Project::Network
we wind up getting the corp_test_case.pm to look like say
use Dtk::Project::Network;
use Dtk::Project::XmlParser; my $xml_conf_obj = new Dtk::Project::XmlParser;
my $network_test = new Dtk::Project::Network;my $arg_hash_ref = $xml_conf_obj->read_config();
while( my ($k,$v) = each % $arg_hash_ref )
{
$network_test->test1($v);
....
}
....
1;or something along that line.
This way you wind up source code controlling all of the base tests in the Perl Modules that are 'required' and passing those Config Values in from the XML document and the various corp_test_case.pm files passed in at the command line.
This way when suddenly you need to add in
test_2365($v);
put that in the Dtk::Project::Network module, add the line to the corp_test_case.pm - fire it up...
This way you wind up with a test tree looking like
../network_test/
goodie_stuff/xml_configfile.conf
the corp_test_case.pm
...
wingnut/xml_configfile.conf
the corp_test_case.pm
../local_side_test/
mainstream/xml_configfile.conf
the corp_test_case.pm
....put it all under source code control, and anyone can check it out... And you have total replicatability...
"easy as cake"
- 2010ciao drieux
ps: do not try this at home boys and girls these are paid professionals using the latest in sasckatchean salmon skin safety equipment...
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
