On 13 September 2011 17:27, Pierre Joye <pierre....@gmail.com> wrote: > hi, > > On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: >> Hi! >> >> On 9/13/11 7:49 AM, Ferenc Kovacs wrote: >>> >>> Stas, I still don't know why do have a custom php.ini, and why is it used. >>> The make test should create tmp-php.ini for you (and copy your >> >> Everybody has custom php.ini, what do you mean "why"? Nobody uses just >> defaults. It is used because -n -c is not passed when you run run-tests. > > Right, but the goal of these tests is to test behavior under certain > conditions. If a test can't be executed in a generic way then its > setting must be changed. It seems to be the case with this one.
Hi all. Surely the test must first determine if it is an appropriate test for the environment. Just like we have tests check to see if an extension is available before running then tests that are tuned to a specific value from a php.ini file (default or custom) must first check that the test is appropriate to the value being tested. As a daft example. If you were testing that the data written to a session file was correct, the format of the serialisation, as defined in session.serialize_handler, has to be taken into consideration. If the php.ini said to use WDDX, testing the "default" format would be incorrect. So, if there are radically different outcomes, depending upon the values read from INI files (default or custom), then multiple tests are needed for each value, or the test needs to branch accordingly and indicate that a particular value is untested - highlighting unexpected changes in the default value (maybe). With reference to the discussion a while ago about what PHP considers the "right" settings for php.ini, in my mind the "default" settings for testing should be the production values. I think this is the case in 5.4, that is running tests with no php.ini is the equivalent to running with php.ini-production which is the defaults built into the engine. If not, then each developer will be having a different INI file and testing will be for different value and test "fixes" on one platform could result in a failure on another. If a test requires a different INI file, then it should set it itself. If it is the case that every developer creates the same ini file for a specific value when testing, then maybe the default value is incorrect. As I see it, testing for different values in INI files can only be done by having multiple tests or by a single test generating multiple sub-tests to check for the known values. Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
