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.
--
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65a Email: christ...@quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax: +43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---------------------------------------------------------------
signature.asc
Description: Digital signature
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
