Actually that and more...
For example:
1) verify all necessary dbms client and server files are in a directory, else fail
2) verify versions of client and server binaries & libraries
3) run a series of queries that pass/fail where desired
4) verify 3rd party binaries work correctly with the dbms server
5) verify os patch and kernel options
6) etc.
This one example would be used to certify a particular dbms version with the local build of the dbms and the local network
I'm doing about 1/2 this by hand now and since I'm lazy, I don't want to keep doing it. This is just an example of a whole series of other applications I wish to put Test::* towards.
Jason L. Froebe
No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1
| [reply] |
You could do pretty much all of this with Perl and Test:: modules if you want. The benefit of Test:: modules is that you get nice output which can be run as a single file, or under something like Test::Harness which gives you a report for a group of tests.
1) verify all necessary dbms client and server files are in a directory, else fail
Write a perl script which reads in the directories of these and then check those values against a static list you constructed. This can be done with Test::More::is_deeply if you have them in order, or Test::More::eq_set if they are not in order (remember though that eq_set is not a Test function and must be wrapped with Test::More::ok).
There may also be a Test:: module out there for specifically checking file existence, I am not sure since I have never had the need. And if there isn't, you could always write one ;-)
2) verify versions of client and server binaries & libraries
I would expect that a combination of file test and shell commands (to libtool or something) would get you the answers you want to know, then just test those answers against your expected values using Test::More
3) run a series of queries that pass/fail where desired
Load DBI and run some tests, checking the output with Test::More
4) verify 3rd party binaries work correctly with the dbms server
I am not sure what this entails, but again, I am sure some shell commands using backticks or system() would get you the answers.
6) verify os patch and kernel options
see the last three answers above ...
Really you can do just about anything with perl assuming you have some kind of programattic access to it. And with a little work, you can hook it into Test::More.
And as I said above, if you develop any new and possibly useful Test:: modules, put them on CPAN and share the wealth.
| [reply] |
| [reply] |
Better yet, use Test-WWW-Mechanize instead of LWP::UserAgent. It's a proper subclass of WWW::Mechanize, which is a proper subclass of LWP::UserAgent, but has some fun testing stuff. It's nice to be able to call, for example
my $agent = Test::WWW::Mechanize( autocheck => 1 );
$agent->get( $homepage );
$agent->html_ok( "Valid HTML" );
| [reply]
[d/l] |
