|more useful options|
Re^3: using Test::* modules for generic testing of non perl stuff?by stvn (Monsignor)
|on Oct 15, 2004 at 21:30 UTC||Need Help??|
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.