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/

Reply via email to