Last modified: 2013-04-08 11:02:19 UTC
Currently running for 1.5 hours on Tesla and no sign of an end. Tests THAT slow to run aren't going to be used by developers. The culprit seems to be recreation of every table for every test. Tried replacing drops with truncates, doesn't seem to improve anything radically.
rephrased to "Parser tests generate too much DB queries" Marking as blocker (since it blocks advancement of parser related bugs). I get a few thousands database queries PER test.
s/much/many/
The parser tests have always retained data between individual test segments -- this is needed for instance to create a page, then refer to that same page. Dropping & recreating tables between individual test segments would cause tests relying on data created earlier in the run to fail, in addition to creating a huge amount of additional slow stuff. Is this some sort of SQLite-specific setup code for parserTests? Or maybe this is in the second copy of the parser tests that's been stashed into the phpunit directory? Does it behave differently from the main parser tests?
(In reply to comment #3) > Or maybe this > is in the second copy of the parser tests that's been stashed into the phpunit > directory? Does it behave differently from the main parser tests? This. It creates a new test for each parser test, and thus goes through the setUp(), tearDown() for each and every parser test.
So.... that doesn't seem wise. It'll just break a lot of the test cases and be super slow for no reason, right?
(note that the design of parser tests is to setup/teardown *MediaWiki program state* for each case while retaining *MediaWiki database state* throughout the entire run)
tagging 'bugsmash' to get it looked at during the Berlin Hackaton 2011 (this week).
I think this was the topic on IRC a while ago, but i think at that time i was told this setup/tear-down procedure on each step was intended to provide consistent state for each step. So to avoid too much complication i'd suggest to create the "testing state" tables only on first call (i.e.: if tables don't exist) and leave them there after the completion of a test. If tables exist just truncate tables (delete some of them as you wan't to retain initial state like user 1, interwiki, page and user 0 for some DBbs). Finally the tables should be left there after the parsertest finish completely as people doing these test usually 1)don't do it on production servers 2)do it multiple times in a row if dealing with a bug. I think it would be better to just add a parameter to parserTests main class to just clean up testing stuff. Parser test will usually not create that much data, so this procedure should be faster and easier on the server resources. Dunno ... thoughts?
I fixed this yesterday in r88755.
