At 19:53 10/28/2002 +0100, Derick Rethans wrote: [...]
Yeah, but that's the problem for windows, which needs some attention anyways.> IMHO we should do a complete overhaul of */tests/* and remove any dl() > code, or come up with something, that will force the modules/ directory > on the testkit. That should be easy by forcing the extensions directory with a hardcoded ini setting in run-tests.php... (I think :)
There's no valid technical/qa reason that you can't run a test suite with the
binary distribution. A simple bat file, which sets up the environment similar to
"make test" would already help a lot.
But IIRC extensions with ms-dev compilation end up in RELEASE_TS...
> This is again a good reason to setup php.ini-test.+1 on that from me as you know :)
> Windows will then be a problem, which kinda makes the dl() thingy troublesome
> as well.
I've been thinking about that, but I dont like it that much. I still
want the test suite to be run with as much outside influence (in the
form of users' ini settings). That's why I think we should go with the
following scenario:
1. all things that really need to be hardcoded should go to the
run-tests.php script (in that array we have).
2. If some test needs specific tests the settings for that go to the
--INI-- section.
(We already do this AFAIK)
For the execution of the run-tests.php script itself we do it like this:
1. Every hardcoded setting which is possible (implicit_flush for example
:) we set with ini_set()
2. If for some reason the above can not be used for settings (like
safe_mode, open_basedir), we should make a php.ini-test which we load as additional
ini file with all these settings. This .ini file is then used to
override settings in the users' .ini file. We only need to check if
settings in this .ini file actually override the users' normal .ini
settings. (We can load this additional .ini with something we pass in
the "make test" target in configure.
Making this work platform independant, easy for the user and with as low maintenance
as possible, is the main issue.
After 4.3-release we can think about a testsuite that will run in the webserver, so we
can test webserver sapi's. I think that one of the reasons that some grave bugs only
get reported after release is because we don't really have a way to stress-test the
server sapi's and given budgets these days not everybody is blessed with a testbox
anymore :)
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
<@Logan> I spent a minute looking at my own code by accident.
<@Logan> I was thinking "What the hell is this guy doing?"
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
