rewriting run-tests.php
| From: | Shane Caraveo | Date: | Tue, 29 Oct 2002 22:22:09 +0000 |
| Subject: | rewriting run-tests.php | ||
| References: | 1 2 3 4 | Groups: | php.qa |
| Request: | Send a blank email to php-qa+get-6479@lists.php.net to get a copy of this message | ||
So I've been doing a bit of work towards having a test system that works for multithreaded builds. This comes out of a conversasion with John Coggeshell at PHPCON last week, and he is going to get involved with working on this as well. As part of this I am working on a complete rewrite of the current run-tests.php script so that it can perform different types of tests. Another part is to make sure it works with older versions of PHP (at least 4.2.3) so that the run-tests script can be run with an existing stable php, executing the seperate executable that is being tested. The types of tests I am currently looking at include:
1. the current command line level tests.
2. tests via http. rather than executing php a http request is made.
3. multithreaded testing.
I want to rewrite it so that these different methods will be able to plug into the test script.
The http tests will provide a way to test scripts through the various sapi modules. Multithread testing can also be accomplished through this by doing several test runs at the same time against the same server.
The more controversial aspect of this is the multithreading tests. I was thinking about this over the weekend and realized there is a realy easy way to test multithreading within php, but the PECL threads extension is required to do that testing. Some on this list may not be familier with what the extension does yet, so a breif explanation of that first.
Basicly, the extension provides a function, thread_include, which takes a filename as a parameter, and starts off a thread to handle that script. The script is then run just as if it were a seperate request started by a sapi module, with the exception that it utilizes the same sapi request data. This works very well at this time. A couple additional functions are in the extension to share variables (currently using serialize and deserialize to move data between threads).
Anyway, the idea is to have a seperate script that is a multithread stub script for the tests. It takes a single test script (phpt) as the parameter, starts x number of threads, and runs the test in each thread. This is to test multiple threads running the same code at aproximately the same time, which should give us a good indication as to the thread safety of those particular functions, at the very least testing for crashers.
So when doing a run-tests (passing a parameter to turn on multithreading testing), the tests are looped through as normal, the stub script is executed which runs the same test in multiple threads and generates a success or failure result. Any single thread failing the test causes the entire test to fail. Only one phpt test is run at a time as the current command line system does.
So this is where I am headed with things. Input is welcome.
Shane