/ 
ASNMTAP-3.002003
River stage zero No dependents
/ ASNMTAP::Asnmtap::Plugins::NPTest

NAME

NPTest - Simplify the testing of Nagios Plugins

DESCRIPTION

This modules provides convenience functions to assist in the testing of Nagios Plugins, making the testing code easier to read and write; hopefully encouraging the development of a more complete test suite for the Nagios Plugins. It is based on the patterns of testing seen in the 1.4.0 release, and continues to use the Test module as the basis of testing.

FUNCTIONS

This module defines three public functions, getTestParameter(...), checkCmd(...) and skipMissingCmd(...). These are exported by default via the use NPTest; statement.

getTestParameter( "ENV_VARIABLE", $brief_description, $default )

$default is optional.

This function allows the test harness developer to interactively request test parameter information from the user. The user can accept the developer's default value or reply "none" which will then be returned as "" for the test to skip if appropriate.

If a parameter needs to be entered and the test is run without a tty attached (such as a cronjob), the parameter will be assigned as if it was "none". Tests can check for the parameter and skip if not set.

Responses are stored in an external, file-based cache so subsequent test runs will use these values. The user is able to change the values by amending the values in the file /var/tmp/NPTest.pm, or by setting the appropriate environment variable before running the test.

The option exists to store parameters in a scoped means, allowing a test harness to a localise a parameter should the need arise. This allows a parameter of the same name to exist in a test harness specific scope, while not affecting the globally scoped parameter. The scoping identifier is the name of the test harness sans the trailing ".t". All cache searches first look to a scoped parameter before looking for the parameter at global scope. Thus for a test harness called "check_disk.t" requesting the parameter "mountpoint_valid", the cache is first searched for "check_disk"/"mountpoint_valid", if this fails, then a search is conducted for "mountpoint_valid".

To facilitate quick testing setup, it is possible to accept all the developer provided defaults by setting the environment variable "NPTEST_ACCEPTDEFAULT" to "1" (or any other perl truth value). Note that, such defaults are not stored in the cache, as there is currently no mechanism to edit existing cache entries, save the use of text editor or removing the cache file completely.

testCmd($command)

Call with ASNMTAP::Asnmtap::Plugins::NPTest->testCmd("./check_disk ...."). This returns a NPTest object which you can then run $object->return_code or $object->output against.

Testing of results would be done in your test script, not in this module.

checkCmd(...)

This function is obsolete. Use testCmd() instead.

This function attempts to encompass the majority of test styles used in testing Nagios Plugins. As each plug-in is a separate command, the typical tests we wish to perform are against the exit status of the command and the output (if any) it generated. Simplifying these tests into a single function call, makes the test harness easier to read and maintain and allows additional functionality (such as debugging) to be provided without additional effort on the part of the test harness developer.

It is possible to enable debugging via the environment variable NPTEST_DEBUG. If this environment variable exists and its value in PERL's boolean context evaluates to true, debugging is enabled.

The function prototype can be expressed as follows:

Parameter 1 : command => DEFINED SCALAR(string)
Parameter 2 : desiredExitStatus => ONE OF
                SCALAR(integer)
                ARRAYREF(integer)
                HASHREF(integer,string)
                UNDEFINED
Parameter 3 : desiredOutput => SCALAR(string) OR UNDEFINED
Parameter 4 : exceptions => HASH(integer,string) OR UNDEFINED
Returns     : SCALAR(integer) as defined by Test::ok(...)

The function treats the first parameter $command as a command line to execute as part of the test, it is executed only once and its exit status ($?>>8) and output are captured.

At this point if debugging is enabled the command, its exit status and output are displayed to the tester.

checkCmd(...) allows the testing of either the exit status or the generated output or both, not testing either will result in neither the Test::ok(...) or Test::skip(...) functions being called, something you probably don't want. Note that each defined test ($desiredExitStatus and $desiredOutput) results in a invocation of either Test::ok(...) or Test::skip(...), so remember this when counting the number of tests to place in the Test::plan(...) call.

Many Nagios Plugins test network services, some of which may not be present on all systems. To cater for this, checkCmd(...) allows the tester to define exceptions based on the command's exit status. These exceptions are provided to skip tests if the test case developer believes the service is not being provided. For example, if a site does not have a POP3 server, the test harness could map the appropriate exit status to a useful message the person running the tests, telling the reason the test is being skipped.

Example:

my %exceptions = ( 2 => "No POP Server present?" );

$t += checkCmd( "./check_pop some args", 0, undef, %exceptions );

Thus, in the above example, an exit status of 2 does not result in a failed test case (as the exit status is not the desired value of 0), but a skipped test case with the message "No POP Server present?" given as the reason.

Sometimes the exit status of a command should be tested against a set of possible values, rather than a single value, this could especially be the case in failure testing. checkCmd(...) support two methods of testing against a set of desired exit status values.

  • Firstly, if $desiredExitStatus is a reference to an array of exit stati, if the actual exit status of the command is present in the array, it is used in the call to Test::ok(...) when testing the exit status.

  • Alternatively, if $desiredExitStatus is a reference to a hash of exit stati (mapped to the strings "continue" or "skip"), similar processing to the above occurs with the side affect of determining if any generated output testing should proceed. Note: only the string "skip" will result in generated output testing being skipped.

skipMissingCmd(...)

If a command is missing and the test harness must Test::skip() some or all of the tests in a given test harness this function provides a simple iterator to issue an appropriate message the requested number of times.

SEE ALSO

Test

The rest of the code, as I have only commented on the major public functions that test harness writers will use, not all the code present in this helper module.

AUTHOR

Copyright (c) 2005 Peter Bray. All rights reserved.

This package is free software and is provided "as is" without express or implied warranty. It may be used, redistributed and/or modified under the same terms as the Nagios Plugins release.