search

pyrus / Pyrus_Developer

Developer tools for building PEAR compatible packages
7 stars 7 forks source link

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

Open boenrobot opened 11 years ago

boenrobot commented 11 years ago

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.

cellog commented 11 years ago

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/pyrus/Pyrus_Developer/issues/19.

boenrobot commented 11 years ago

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.