Apache-Test
view release on metacpan or search on metacpan
lib/Apache/Test.pm view on Meta::CPAN
For example:
plan tests => 5, need_min_module_version(CGI => 2.81);
requires C<CGI.pm> version 2.81 or higher.
Currently works only for perl modules.
=item need
plan tests => 5,
need 'LWP',
{ "perl >= 5.8.0 and w/ithreads is required" =>
($Config{useperlio} && $] >= 5.008) },
{ "not Win32" => sub { $^O eq 'MSWin32' },
"foo is disabled" => \&is_foo_enabled,
},
'cgid';
need() is more generic function which can impose multiple requirements
at once. All requirements must be satisfied.
need()'s argument is a list of things to test. The list can include
scalars, which are passed to need_module(), and hash references. If
hash references are used, the keys, are strings, containing a reason
for a failure to satisfy this particular entry, the values are the
condition, which are satisfaction if they return true. If the value is
0 or 1, it used to decide whether the requirements very satisfied, so
you can mix special C<need_*()> functions that return 0 or 1. For
example:
plan tests => 1, need 'Compress::Zlib', 'deflate',
need_min_apache_version("2.0.49");
If the scalar value is a string, different from 0 or 1, it's passed to
I<need_module()>. If the value is a code reference, it gets executed
at the time of check and its return value is used to check the
condition. If the condition check fails, the provided (in a key)
reason is used to tell user why the test was skipped.
In the presented example, we require the presence of the C<LWP> Perl
module, C<mod_cgid>, that we run under perl E<gt>= 5.7.3 on Win32.
It's possible to put more than one requirement into a single hash
reference, but be careful that the keys will be different.
It's also important to mention to avoid using:
plan tests => 1, requirement1 && requirement2;
technique. While test-wise that technique is equivalent to:
plan tests => 1, need requirement1, requirement2;
since the test will be skipped, unless all the rules are satisfied,
it's not equivalent for the end users. The second technique, deploying
C<need()> and a list of requirements, always runs all the requirement
checks and reports all the missing requirements. In the case of the
first technique, if the first requirement fails, the second is not
run, and the missing requirement is not reported. So let's say all the
requirements are missing Apache modules, and a user wants to satisfy
all of these and run the test suite again. If all the unsatisfied
requirements are reported at once, she will need to rebuild Apache
once. If only one requirement is reported at a time, she will have to
rebuild Apache as many times as there are elements in the C<&&>
statement.
Also see plan().
=item under_construction
plan tests => 5, under_construction;
skip all tests, noting that the tests are under construction
=item skip_reason
plan tests => 5, skip_reason('my custom reason');
skip all tests. the reason you specify will be given at runtime.
if no reason is given a default reason will be used.
=back
=head1 Additional Configuration Variables
=over 4
=item basic_config
my $basic_cfg = Apache::Test::basic_config();
$basic_cfg->write_perlscript($file, $content);
C<basic_config()> is similar to C<config()>, but doesn't contain any
httpd-specific information and should be used for operations that
don't require any httpd-specific knowledge.
=item config
my $cfg = Apache::Test::config();
my $server_rev = $cfg->{server}->{rev};
...
C<config()> gives an access to the configuration object.
=item vars
my $serverroot = Apache::Test::vars->{serverroot};
my $serverroot = Apache::Test::vars('serverroot');
my($top_dir, $t_dir) = Apache::Test::vars(qw(top_dir t_dir));
C<vars()> gives an access to the configuration variables, otherwise
accessible as:
$vars = Apache::Test::config()->{vars};
If no arguments are passed, the reference to the variables hash is
returned. If one or more arguments are passed the corresponding values
are returned.
( run in 0.526 second using v1.01-cache-2.11-cpan-a1f116cd669 )