Le 11 août 09 à 22:51, dan nessett a écrit :
--- On Tue, 8/11/09, Alexandre Emsenhuber
<alex.emsenhuber(a)bluewin.ch> wrote:
+1, we could maybe write our own test system that
can be
based on the
new Maintenance class, since we already some test scripts
in /
maintenance/ (cdb-test.php, fuzz-tester.php,
parserTests.php,
preprocessorFuzzTest.php and syntaxChecker.php). Porting
tests such as
parser to PHPUnit is a pain, since it has no native way to
write a
test suite that has a "unknow" number of tests to run.
Rewriting parserTests as php unit tests would be a horrible waste of
time. parserTests works and it provides a reasonable service. One
problem, however, is how do we fix the parser? It seems it is a
pretty complex code system (when I ran a MacGyver test on
parserTests, 141 files were accessed, most of which are associated
with the parser). I have been thinking about this, but those
thoughts are not yet sufficiently clear to make public yet.
On the other hand, taking the parserTests route and doing all of our
own test infrastructure would also be a good deal of work. There are
tools out there (phpuint and prove) that are useful. In my view
creating a test infrastructure from scratch would unnecessarily
waste time and resources.
Dan
My idea is the move the "backend" of ParserTest (parserTests.txt file
processing, result reporting, ...) and the TestRecorder stuff to
something like a MediaWikiTests class that extends Maintenance and
move the rest in a file in /maintenance/tests/ (to be created) and re-
use the backend to have files that have the same format, but test's
input could be raw PHP code (a bit like PHP core's tests) with a new
config variable that's like $wgParserTestFiles but for these kind of
test. This mostly concerns the actual tests in /tests/ and /t/inc/).
We can also port cdb-test.php, fuzz-tester.php,
preprocessorFuzzTest.php and syntaxChecker.php to this new system and
then create a script in /maintenance/ that runs all the tests in /
maintenance/tests/. This allows to also upload all the tests to
CodeReview, not only the parser tests. A benefit is that we can get
ride of /tests/ and /t/.
Alexandre Emsenhuber (ialex)