Provided by: libapache2-mod-perl2_2.0.12-1build1_amd64 bug

NAME

       Apache::TestUtil - Utility functions for writing tests

SYNOPSIS

         use Apache::Test;
         use Apache::TestUtil;

         ok t_cmp("foo", "foo", "sanity check");
         t_write_file("filename", @content);
         my $fh = t_open_file($filename);
         t_mkdir("/foo/bar");
         t_rmtree("/foo/bar");
         t_is_equal($a, $b);

DESCRIPTION

       "Apache::TestUtil" automatically exports a number of functions useful in writing tests.

       All the files and directories created using the functions from this package will be automatically
       destroyed at the end of the program execution (via END block). You should not use these functions other
       than from within tests which should cleanup all the created directories and files at the end of the test.

FUNCTIONS

       t_cmp()
             t_cmp($received, $expected, $comment);

           t_cmp() prints the values of $comment, $expected and $received. e.g.:

             t_cmp(1, 1, "1 == 1?");

           prints:

             # testing : 1 == 1?
             # expected: 1
             # received: 1

           then  it  returns the result of comparison of the $expected and the $received variables. Usually, the
           return value of this function is fed directly to the ok() function, like this:

             ok t_cmp(1, 1, "1 == 1?");

           the third argument ($comment) is optional, mostly useful for telling what the comparison is trying to
           do.

           It is valid to use "undef" as an expected value. Therefore:

             my $foo;
             t_cmp(undef, $foo, "undef == undef?");

           will return a true value.

           You can compare any two data-structures with t_cmp(). Just make sure that if  you  pass  non-scalars,
           you  have  to  pass  their  references.  The datastructures can be deeply nested. For example you can
           compare:

             t_cmp({1 => [2..3,{5..8}], 4 => [5..6]},
                   {1 => [2..3,{5..8}], 4 => [5..6]},
                   "hash of array of hashes");

           You can also compare the second argument against the first as a regex. Use the "qr//" function in the
           second argument. For example:

             t_cmp("abcd", qr/^abc/, "regex compare");

           will do:

             "abcd" =~ /^abc/;

           This function is exported by default.

       t_filepath_cmp()
           This function is used to compare two filepaths via t_cmp().  For non-Win32, it  simply  uses  t_cmp()
           for  the  comparison,  but  for  Win32,  Win32::GetLongPathName() is invoked to convert the first two
           arguments to their DOS long pathname. This is useful when there is a possibility the two paths  being
           compared are not both represented by their long or short pathname.

           This function is exported by default.

       t_debug()
             t_debug("testing feature foo");
             t_debug("test", [1..3], 5, {a=>[1..5]});

           t_debug()  prints  out  any datastructure while prepending "#" at the beginning of each line, to make
           the debug printouts comply with "Test::Harness"'s requirements. This function should be  always  used
           for debug prints, since if in the future the debug printing will change (e.g. redirected into a file)
           your tests won't need to be changed.

           the  special  global variable $Apache::TestUtil::DEBUG_OUTPUT can be used to redirect the output from
           t_debug() and related calls such as t_write_file().  for example, from a server-side test  you  would
           probably need to redirect it to STDERR:

             sub handler {
               plan $r, tests => 1;

               local $Apache::TestUtil::DEBUG_OUTPUT = \*STDERR;

               t_write_file('/tmp/foo', 'bar');
               ...
             }

           left  to  its  own devices, t_debug() will collide with the standard HTTP protocol during server-side
           tests, resulting in a situation both confusing difficult  to  debug.   but  STDOUT  is  left  as  the
           default,  since  you probably don't want debug output under normal circumstances unless running under
           verbose mode.

           This function is exported by default.

       t_write_test_lib()
             t_write_test_lib($filename, @lines)

           t_write_test_lib() creates a new file at $filename or overwrites the existing file with  the  content
           passed  in  @lines.   The  file  is  created  in a temporary directory which is added to @INC at test
           configuration time.  It is intended to be used for creating temporary packages for testing which  can
           be modified at run time, see the Apache::Reload unit tests for an example.

       t_write_file()
             t_write_file($filename, @lines);

           t_write_file()  creates  a  new  file  at  $filename or overwrites the existing file with the content
           passed in @lines. If only the $filename is passed, an empty file will be created.

           If parent directories of $filename don't exist they will be automagically created.

           The generated file will be automatically deleted at the end of the program's execution.

           This function is exported by default.

       t_append_file()
             t_append_file($filename, @lines);

           t_append_file() is similar to t_write_file(), but it  doesn't  clobber  existing  files  and  appends
           @lines to the end of the file. If the file doesn't exist it will create it.

           If parent directories of $filename don't exist they will be automagically created.

           The  generated  file  will  be  registered  to  be  automatically deleted at the end of the program's
           execution, only if the file was created by t_append_file().

           This function is exported by default.

       t_write_shell_script()
             Apache::TestUtil::t_write_shell_script($filename, @lines);

           Similar to t_write_file() but  creates  a  portable  shell/batch  script.  The  created  filename  is
           constructed  from  $filename  and  an  appropriate  extension automatically selected according to the
           platform the code is running under.

           It returns the extension of the created file.

       t_write_perl_script()
             Apache::TestUtil::t_write_perl_script($filename, @lines);

           Similar to t_write_file() but creates a executable Perl script with correctly set shebang line.

       t_open_file()
             my $fh = t_open_file($filename);

           t_open_file() opens a file $filename for writing and returns the file handle to the opened file.

           If parent directories of $filename don't exist they will be automagically created.

           The generated file will be automatically deleted at the end of the program's execution.

           This function is exported by default.

       t_mkdir()
             t_mkdir($dirname);

           t_mkdir() creates a directory $dirname. The operation will  fail  if  the  parent  directory  doesn't
           exist.

           If parent directories of $dirname don't exist they will be automagically created.

           The generated directory will be automatically deleted at the end of the program's execution.

           This function is exported by default.

       t_rmtree()
             t_rmtree(@dirs);

           t_rmtree() deletes the whole directories trees passed in @dirs.

           This function is exported by default.

       t_chown()
             Apache::TestUtil::t_chown($file);

           Change  ownership  of  $file  to  the  test's  User/Group.   This function is noop on platforms where
           chown(2) is unsupported (e.g. Win32).

       t_is_equal()
             t_is_equal($a, $b);

           t_is_equal() compares any two datastructures and returns 1 if they are exactly the same, otherwise 0.
           The datastructures can be nested hashes, arrays, scalars, undefs or a combination of  any  of  these.
           See t_cmp() for an example.

           If $b is a regex reference, the regex comparison "$a =~ $b" is performed. For example:

             t_is_equal($server_version, qr{^Apache});

           If comparing non-scalars make sure to pass the references to the datastructures.

           This function is exported by default.

       t_server_log_error_is_expected()
           If  the  handler's  execution  results in an error or a warning logged to the error_log file which is
           expected, it's a good idea to have a disclaimer printed before the error itself, so one can tell real
           problems with tests from expected errors. For example when testing  how  the  package  behaves  under
           error conditions the error_log file might be loaded with errors, most of which are expected.

           For example if a handler is about to generate a run-time error, this function can be used as:

             use Apache::TestUtil;
             ...
             sub handler {
                 my $r = shift;
                 ...
                 t_server_log_error_is_expected();
                 die "failed because ...";
             }

           After running this handler the error_log file will include:

             *** The following error entry is expected and harmless ***
             [Tue Apr 01 14:00:21 2003] [error] failed because ...

           When  more than one entry is expected, an optional numerical argument, indicating how many entries to
           expect, can be passed. For example:

             t_server_log_error_is_expected(2);

           will generate:

             *** The following 2 error entries are expected and harmless ***

           If the error is generated at compile time, the logging must be done in the BEGIN block  at  the  very
           beginning of the file:

             BEGIN {
                 use Apache::TestUtil;
                 t_server_log_error_is_expected();
             }
             use DOES_NOT_exist;

           After attempting to run this handler the error_log file will include:

             *** The following error entry is expected and harmless ***
             [Tue Apr 01 14:04:49 2003] [error] Can't locate "DOES_NOT_exist.pm"
             in @INC (@INC contains: ...

           Also see "t_server_log_warn_is_expected()" which is similar but used for warnings.

           This function is exported by default.

       t_server_log_warn_is_expected()
           "t_server_log_warn_is_expected()" generates a disclaimer for expected warnings.

           See the explanation for "t_server_log_error_is_expected()" for more details.

           This function is exported by default.

       t_client_log_error_is_expected()
           "t_client_log_error_is_expected()"  generates  a  disclaimer  for expected errors. But in contrast to
           "t_server_log_error_is_expected()" called by the client side of the script.

           See the explanation for "t_server_log_error_is_expected()" for more details.

           For example the following client script fails to find the handler:

             use Apache::Test;
             use Apache::TestUtil;
             use Apache::TestRequest qw(GET);

             plan tests => 1;

             t_client_log_error_is_expected();
             my $url = "/error_document/cannot_be_found";
             my $res = GET($url);
             ok t_cmp(404, $res->code, "test 404");

           After running this test the error_log file will include an entry similar to the following snippet:

             *** The following error entry is expected and harmless ***
             [Tue Apr 01 14:02:55 2003] [error] [client 127.0.0.1]
             File does not exist: /tmp/test/t/htdocs/error

           When more than one entry is expected, an optional numerical argument, indicating how many entries  to
           expect, can be passed. For example:

             t_client_log_error_is_expected(2);

           will generate:

             *** The following 2 error entries are expected and harmless ***

           This function is exported by default.

       t_client_log_warn_is_expected()
           "t_client_log_warn_is_expected()" generates a disclaimer for expected warnings on the client side.

           See the explanation for "t_client_log_error_is_expected()" for more details.

           This function is exported by default.

       t_catfile('a', 'b', 'c')
           This  function is essentially "File::Spec->catfile", but on Win32 will use "Win32::GetLongpathName()"
           to convert the result to a long path name (if the result is an absolute file).  The function  is  not
           exported by default.

       t_catfile_apache('a', 'b', 'c')
           This    function    is    essentially    "File::Spec::Unix->catfile",   but   on   Win32   will   use
           "Win32::GetLongpathName()" to convert the result to a long path name (if the result  is  an  absolute
           file).   It  is  useful  when comparing something to that returned by Apache, which uses a Unix-style
           specification with forward slashes for directory separators. The function is not exported by default.

       t_start_error_log_watch(), t_finish_error_log_watch()
           This pair of functions provides an easy interface  for  checking  the  presence  or  absence  of  any
           particular message or messages in the httpd error_log that were generated by the httpd daemon as part
           of  a  test  suite.   It  is  likely,  that  you  should  proceed  this  with  a  call  to one of the
           t_*_is_expected() functions.

             t_start_error_log_watch();
             do_it;
             ok grep {...} t_finish_error_log_watch();

           Another usage case could be a handler that emits some debugging messages to the  error_log.  Now,  if
           this  handler  is called in a series of other test cases it can be hard to find the relevant messages
           manually. In such cases the following sequence in the test file may help:

             t_start_error_log_watch();
             GET '/this/or/that';
             t_debug t_finish_error_log_watch();

       t_start_file_watch()
             Apache::TestUtil::t_start_file_watch('access_log');

           This function is similar to "t_start_error_log_watch()" but allows for other files  than  "error_log"
           to be watched. It opens the given file and positions the file pointer at its end. Subsequent calls to
           "t_read_file_watch()"  or  "t_finish_file_watch()" will read lines that have been appended after this
           call.

           A file name can be passed as parameter. If omitted or undefined the "error_log" is  opened.  Relative
           file name are evaluated relative to the directory containing "error_log".

           If  the  specified  file does not exist (yet) no error is returned. It is assumed that it will appear
           soon. In this case "t_{read,finish}_file_watch()" will open the  file  silently  and  read  from  the
           beginning.

       t_read_file_watch(), t_finish_file_watch()
             local $/ = "\n";
             $line1=Apache::TestUtil::t_read_file_watch('access_log');
             $line2=Apache::TestUtil::t_read_file_watch('access_log');

             @lines=Apache::TestUtil::t_finish_file_watch('access_log');

           This pair of functions reads the file opened by "t_start_error_log_watch()".

           As does the core "readline" function, they return one line if called in scalar context, otherwise all
           lines until end of file.

           Before  calling  "readline"  these functions do not set $/ as does "t_finish_error_log_watch". So, if
           the file has for example a fixed record length use this:

             {
               local $/=\$record_length;
               @lines=t_finish_file_watch($name);
             }

       t_file_watch_for()
             @lines=Apache::TestUtil::t_file_watch_for('access_log',
                                                       qr/condition/,
                                                       $timeout);

           This function reads the file from the current position and looks for  the  first  line  that  matches
           "qr/condition/".  If  no  such  line could be found until end of file the function pauses and retries
           until either such a line is found or the timeout (in seconds) is reached.

           In scalar or void context only the matching line is returned. In list  context  all  read  lines  are
           returned with the matching one in last position.

           The function uses "\n" and end-of-line marker and waits for complete lines.

           The timeout although it can be specified with sub-second precision is not very accurate. It is simply
           multiplied by 10. The result is used as a maximum loop count. For the intented purpose this should be
           good enough.

           Use  this function to check for logfile entries when you cannot be sure that they are already written
           when the test program reaches the point, for example to check for messages  that  are  written  in  a
           PerlCleanupHandler or a PerlLogHandler.

            ok t_file_watch_for 'access_log', qr/expected log entry/, 2;

           This call reads the "access_log" and waits for maximum 2 seconds for the expected entry to appear.

AUTHOR

       Stas Bekman <stas@stason.org>, Torsten Förtsch <torsten.foertsch@gmx.net>

SEE ALSO

       perl(1)

perl v5.34.0                                       2022-02-06                              Apache::TestUtil(3pm)