Apache::TestRunPHP(3)
π Apache::TestRunPHP β like, the whole entire manual, but make it make sense π
okay so first things first, before we even get into it: this is Apache::TestRunPHP(3), and it lives in the User Contributed Perl Documentation section. that's the vibe. that's the whole thing. now let's go π«Ά
β¨ NAME β¨
Apache::TestRunPHP β this is the one that configures and runs a PHP-based test suite. yes bestie, PHP tests, run through Perl scaffolding. it's giving crossover episode π
π¦ SYNOPSIS π¦
use Apache::TestRunPHP;
Apache::TestRunPHP->new->run(@ARGV);
that's it. that's the whole entry point. two lines and you're a main character β¨
π DESCRIPTION π
okay so the Apache::TestRunPHP package controls the configuration and running of the test suite for PHP-based tests. it's a subclass of Apache::TestRun, and functionally it's the sibling of Apache::TestRunPerl. same energy, different language π
for all the deets on the available API, go read the Apache::TestRun manpage. like, actually read it. iykyk π
π EXAMPLE π
TestRunPHP works almost identically to TestRunPerl, but if you're brand new to Apache-Test, here's a quick getting-started guide. and fr fr, check the links at the end of this document for places to find more details π§
because Apache-Test is a Perl-based testing framework, we start from a Makefile.PL. that file should have the following lines, in addition to the standard Makefile.PL parts:
use Apache::TestMM qw(test clean);
use Apache::TestRunPHP ();
Apache::TestMM::filter_args();
Apache::TestRunPHP->generate_script();
so what does all that do? generate_script() creates a script named t/TEST β that's the gateway to the Perl testing harness, and it's what gets invoked when you call make test. meanwhile filter_args() accepts some Apache::Test-specific arguments and passes them along β¨
for example, if you wanted to point at a specific httpd installation, you'd invoke Makefile.PL like this:
$ perl Makefile.PL -httpd /my/local/apache/bin/httpd
and then /my/local/apache/bin/httpd gets propagated throughout the rest of the process. slay, honestly π
β οΈ ok important one: note that PHP needs to be active within Apache prior to configuring the test framework as shown above. either because PHP is compiled into thehttpdbinary statically, or through an activeLoadModulestatement within the configuration located in/my/local/apache/conf/httpd.conf. other required modules are the (very common)mod_aliasandmod_env. don't skip this part bestie, i'm begging π
now, just like with Apache::TestRun and Apache::TestRunPerl, you can place client-side Perl test scripts under t/ β things like t/01basic.t β and Apache-Test will run those scripts when you call make test π
but here's the part that makes Apache::TestRunPHP unique: there's added magic specifically tailored to a PHP environment. let's get into the mechanics π₯
πΈ the pattern-matching bit πΈ
Apache::TestRunPHP will look for PHP test scripts that match this pattern:
t/response/TestFoo/bar.php
where Foo and bar can be literally anything you like, and t/response/Test* is case sensitive (do not test me on this, it's literally in the name). when this format is adhered to, Apache::TestRunPHP will create an associated Perl test script called t/foo/bar.t, which gets executed when you call make test β¨
and all bar.t does is issue a simple GET to bar.php, leaving the actual testing to bar.php. so in essence? you can fully forget that bar.t even exists. it's an NPC. it's background noise. it's not the main character π
π¦ what does bar.php even look like π¦
great question, bestie. here's an example:
<?php
print "1..1\n";
print "ok 1\n"
?>
if it looks odd, that's ok because it is odd π. i could explain exactly what this means, but honestly it isn't important to understand the gory details. instead, it's sufficient to understand that when Apache::Test calls bar.php, it feeds the results directly to Test::Harness β a module that comes with every Perl installation β and Test::Harness expects what it receives to be formatted in a very specific way π
by itself, all of this is pretty useless, so Apache::Test provides PHP testers with something much better. here's a much better example:
<?php
# import the Test::More emulation layer
# see
# http://search.cpan.org/dist/Test-Simple/lib/Test/More.pm
# for Perl's documentation - these functions should behave
# in the same way
require 'test-more.php';
# plan() the number of tests
plan(6);
# call ok() for each test you plan
ok ('foo' == 'foo', 'foo is equal to foo');
ok ('foo' != 'foo', 'foo is not equal to foo');
# ok() can be other things as well
is ('bar', 'bar', 'bar is bar');
is ('baz', 'bar', 'baz is baz');
isnt ('bar', 'beer', 'bar is not beer');
like ('bar', '/ar$/', 'bar matches ar$');
diag("printing some debugging information");
# whoops! one too many tests. I wonder what will happen...
is ('biff', 'biff', 'baz is a baz');
?>
ok so, the include library test-more.php is automatically generated by Apache::TestConfigPHP, and the configurations get tweaked in such a way that your PHP scripts can find it without issue. no cap, it just works π§
the functions provided by test-more.php are equivalent in name and function to those in Test::More, a standard Perl testing library β so you can go read that manpage for details on the syntax and functionality of each one. it's giving "the docs already exist, go read them" π
π running the tests π
at this point, we have enough in place to run some tests from PHP-land: a Makefile.PL to configure Apache for us, and a PHP script in t/response/TestFoo/bar.php to send some results out to the testing engine. we're so back π₯
issuing make test would start Apache, issue the request to bar.php, generate a report, and shut down Apache. iconic behavior, honestly π
that report would look something like this after running the tests in verbose mode (eg. make test TEST_VERBOSE=1):
t/php/bar....1..6
ok 1 - foo is equal to foo
not ok 2 - foo is not equal to foo
# Failed test (/src/devel/perl-php-test/t/response/TestFoo/bar.php at line 13)
ok 3 - bar is bar
not ok 4 - baz is baz
# Failed test (/src/devel/perl-php-test/t/response/TestFoo/bar.php at line 17)
# got: 'baz'
# expected: 'bar'
ok 5 - bar is not beer
ok 6 - bar matches ar$
# printing some debugging information
ok 7 - baz is a baz
FAILED tests 2, 4, 7
Failed 3/6 tests, 50.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/php/bar.t 6 3 50.00% 2 4 7
Failed 1/1 test scripts, 0.00% okay. 1/6 subtests failed, 83.33% okay.
note that the actual test file that was run was t/php/bar.t. this file is autogenerated based on the t/response/TestFoo/bar.php pattern of your PHP script. t/php/bar.t happens to be written in Perl, but you really don't need to worry about it too much π«Ά
β¨ an interesting aside β¨
and ooh, as an interesting aside: if you're using perl-5.8.3 or later, you can actually create your own t/foo.php client-side scripts and they will be run via php (using our php.ini). but more on that later... π dramatic pause π
π SEE ALSO π
the best source of information about using Apache-Test with PHP (at this time) is probably the talk given at ApacheCon 2004 β <http://xrl.us/phpperl> β as well as the code from the talk β <http://xrl.us/phpperlcode> π
there's also the online tutorial <http://perl.apache.org/docs/general/testing/testing.html>, which has all of the mod_perl-specific syntax and features that have been ported to PHP with this class. it's giving β¨ lore β¨
π AUTHOR π
Apache-Test is a community effort, maintained by a group of dedicated volunteers. we love a collaborative queen πΈ
questions can be asked at the test-dev <at> httpd.apache.org list. for more information see: http://httpd.apache.org/test/ π«Ά
and that's the whole page bestie, you ate that. go forth and test your PHP π
okay so this was Apache::TestRunPHP(3) from the User Contributed Perl Documentation, generated with perl v5.42.3 and dated 2023-10-21. periodt. ππ¦β¨
π¦ where this page comes from
- nixos 26.05: mod_perl 2.0.13
- nixpkgs unstable: mod_perl 2.0.13
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms