[run-phpt] Support --REDIRECTTEST-- #19

Activity

1. cellog commented on Sep 27, 2012

   

   cellog

   on Sep 27, 2012

   Contributor

   More actions

   Hi,

   I didn't implement redirecttest because I was not sure how it worked, and
   nobody in PEAR was using it. Can you briefly describe how it works?

   On Sep 26, 2012, at 16:33, Vasil Rangelov notifications@github.com wrote:

   The --REDIRECTTEST-- section is not at all supported currently by the
   run-phpt command.

   I use it extensively to test pear2/Cache_SHM, and due to this lack of
   support, I'm currently using run-tests.php... which sucks, because this
   doesn't let me collect code coverage like run-phpt does.

   —
   Reply to this email directly or view it on
   GitHubhttps://github.com//issues/19.
2. boenrobot commented on Sep 27, 2012

   

   boenrobot

   on Sep 27, 2012

   ContributorAuthor

   More actions

   Hi.

   Haven't seen you in a good while... nice to see you around again ^_^ .

   Here's the "official spec" so to speak:
   http://qa.php.net/phpt_details.php#redirecttest_section

   Basically, you have code being eval()-ed that in the end must return an array that has at least a key called "TESTS". The value of this key is a new folder of tests to be executed (relative to the phpt file's location... I think).

   All of those tests are executed with settings defined by other members of the returned array, such as "GET" for get parameters, "ENV" for environment variables, etc. (just like the appropriate sections). I think individual tests are allowed to override the given common settings with their own.

   A key reason for using it is that the --SKIPIF-- section of the file is executed before the redirect just once, so you can simply skip a whole group of tests if they don't meet a condition and/or execute the same group of tests, but with different parameters.

   In my case, I do both of those - pear2/Cache_SHM has "adapters" for different extensions, and for each one, I have a single phpt file in which I check the extension, and redirect to tests applicable to all adapters, except that along with the redirect, I supply a GET parameter that tells the test to use the adapter for the extension that was just checked. This way, I ensure all adapters have the common functionality covered.