developer.

It is possible to enable debugging via the environment variable
C<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 C<$command> as a command line
to execute as part of the test, it is executed only once and its exit
status (C<$?E<gt>E<gt>8>) and output are captured.

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

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

Many Nagios Plugins test network services, some of which may not be
present on all systems. To cater for this, C<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 =E<gt> "No POP Server present?" );

$t += checkCmd( "./check_pop I<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. C<checkCmd(...)> support two methods
of testing against a set of desired exit status values.

=over

=item *

Firstly, if C<$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 C<Test::ok(...)> when testing the
exit status.

=item *

Alternatively, if C<$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.

=back

=item C<skipMissingCmd(...)>

If a command is missing and the test harness must C<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.

=back

=head1 SEE ALSO

L<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.

=head1 AUTHOR

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

This package is free software and is provided "as is" without express