On 2011.4.13 1:50 AM, Jozef Kutej wrote: > <cite>It turned out that there is quite a lot that can go wrong.</cite> > > Found this gem in our internal wiki. :-) > > My question is regarding the post-install testing. Normally the test are run > before installation and then discarded with all the rest of the distribution > files. But what possibilities do we have about testing of already installed > code? Is anyone working on this concept?
Are you talking about integrity testing, making sure the system still has all their pieces and they still work? Or runtime testing, essentially a combination of asserts and logging which run from inside the code to check that the system is internally consistent? For the former, you can run the shipped module tests on your installed code. Run them with prove and leave off the -l. The two issues there is they may want bits of the source directory, so you're best off running it from the original source directory. #2 is the tests might hard code @INC to use the source library so you'll have to find and knock those out. You can also write whatever tests you like, using Test::More and friends, and run them periodically against your installed code. Just make sure they're not destructive. For the latter, there is traditional asserts (Carp::Assert, Carp::Assert::More), and design-by-contract (Sub::Contract) to start. I experimented with putting tests right in the code with Test::AtRuntime. The results go to a log file which can then be watched for failures. It has some issues: it's a source filter; it will chew up memory needlessly storing test history; test functions aren't designed to be fast... but the idea is solid. -- 184. When operating a military vehicle I may *not* attempt something "I saw in a cartoon". -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/