Into the Workings

In a normal case with a correct printer test, the call to lpq_busy() in line 29 uses the function defined in line 49 to invoke lpq and check whether the print queue has received a job. The print queue is empty on any newly installed system; the initial test in line 29 thus reports success if lpq_busy() returns a value of false.

Next, the Path::Tiny CPAN module's spew() function writes a text string to a temporary file, which system() sends to the print queue using the lpr command-line tool. The call to lpr should return an exit code of  , which is verified by the test suite function is. When lpr returns, the job is already in the print queue, where a subsequent call to lpq will show it if everything went as it should.

The while loop in line 40 now checks every second whether the job actually disappeared from the queue; this is a sure sign that it has been sent to the printer and that the test has finally been successfully completed.

After these five tests, done_testing() in line 47 wraps up and reports to the controlling test suite that nothing crashed in the meantime with a text string of 1..5, a moniker for five completed test cases.

Part of the Whole

If the system test launches one or multiple test scripts of this kind, the scripts are typically invoked with a test runner, such as prove, which comes with the Perl distribution. This tool receives the output from individual tests and, if successful, only outputs a summary of the results. In case of error, other details are output that help to troubleshoot the root cause. Figure 4 shows the output after a successful run; for better structuring, it makes sense to run multiple scripts rather than one, potentially using a glob character, as in

$ prove "/var/tests/*

Figure 4: The prove test runner summarizes the output of one or multiple test scripts.

The important thing is to automate everything rather than relying on individual steps that need manual intervention.

Well Packaged

But, how do you bootstrap the test on a new system? In other words, how does the test suite happen to be in place on the system with the installation you want to test? It makes sense to bundle the suite in a package using your distribution's package format, push the package to the repository, and install it from there with the help of the package manager.

The easiest approach uses the fpm [4] packager, which supports Debian's .deb format, Red Hat's .rpm, and the OS X .pkg format. Figure 5 shows the tool wrapping up a Debian package by the name of allmytests. Because the location of the script on the target system will be /var/tests, the build script first copies it into a newly local directory hierarchy var/tests and then points fpm to it with the -s dir option.

Figure 5: The versatile packager fpm builds a Debian package from the test suite.

Because the script requires the CPAN Path::Tiny module, which fortunately already exists as package libpath-tiny-perl in the Debian repository, fpm simply includes it with the -d option. If you then run sudo apt-get install to install the allmytests package from the repository, the package manager picks up the dependent package from the repository and elegantly resolves the dependencies.

If the Perl core is not part of the distribution, you can install it on the system in the same way with another -d option. If the distribution is missing a CPAN module not yet available as a package, the Carton module [5] introduced in a previous column will help to bundle it with the test suite. As your test suite keeps growing, you can be agile by making frequent changes to the system without losing sleep. The test suite will have your back by avoiding potential regressions.