Hi Daniel,
On Wed, Jun 27, 2012 at 09:59:19PM +0200, Daniel Kinzler wrote:
- MediaWikiTestCase will notice this group and use temporary tables instead of
the wiki database's actual tables. The temporary tables are re-created for every test. This protected the wiki from modifications through test cases, and isolates test. So far, so good.
The picture you're painting here is a bit too pessimistic ... ... performance-wise.
The tables are /not/ recreated for each test. Run for example the tests in the maintenance subdirectory. 119 tests. 23 database tests. But MediaWikiTestCase::initDB is called just /once/. (Using MySQL backend)
However, the tables' data (a single user, and a single page with a single revision) is re-injected for each test---but without removing the data first.
And as a matter of fact, (currently) nothing in the way database unit tests work isolates the database to a single test. (At least for MySQL) everything happens on the very same database connection. To properly isolate (at least table-wise), you'll have to use the MediaWikiTestCase::tablesUsed array. :-(
But none the less. You are right: Yes, the current situation towards Database tests is sub-optimal ;-)
[ Fighting unit test slowness by separate read-only Database tests ] What do you think? Is this feasible?
While you're approach is certainly feasible, I am not too sure whether your approach will cut off much run time.
Of the ~950 Database tests: ~70 do not carry out SQL Statements [1] (Most of them probably could be treated with or without your approach) ~30 carry out at least one read, but no writes [1] (obviously, they benefit from your approach) ~850 tests would have to be inspected by hand whether they can benefit from your approach. And one would have to merge their data into a /single/ fixture :-(
Note however, that of those ~950 Database tests, ~700 are parser tests. So gaining considerable speed depends on the handling of those.
Maybe attacking those parser tests directly will solve the database-caused performance problem for you without going through the trouble of adding read-only Database tests?
Kind regards, Christian
P.S.: On a related note ... one could think about mocking the database as a whole for PHPUnit tests. Thereby, one would get rid of unnecessary database coupling for unit testing, get better control/detection of side effects, and really solve the database performance problem for unit tests in one go.
[1] In addDBData / the test function itself.