On 01/07/12 13:49, Christian Aistleitner wrote:
One might think so, yes. But as I said, one would mock /above/ the SQL layer. For typical database operations, SQL would not even get generated in the first place!
Consider for example code containing $db->insert( $param1, $param2, ... );
The mock db's insert function would compare $param1, $param2, ... against the invocations the test setup injected. If there is no match, the test fails. If there is a match, the mock returns the corresponding return value right away. No generating SQL. No call to $db->tableName. No call to $db->makeList. No call to $db->query. No nothing. \o/
But maybe you hinted at DatabaseBase::query? DatabaseBase::query should not be used directly, and it's hardly is. We can go for straight for parameter comparison there as well. No need to parse the SQL.
Unit testing is about decoupling and testing things in isolation. With DatabaseBase and the corresponding factories, MediaWiki has a layer that naturally decouples business logic from direct database access.
Use the decoupling, Luke!
Christian
I was thinking on it. Some operations are "easy", insert a field, select a field, you can perform the joins in php. But you also need table schema knowledge. select('*', 'user'), insert() which is generating a new id, an insert which is violating uniqueness of a primary key, transactions... It can obviously be done, but beware of the corner cases! As nifty as it would be, it may need quite more effort than expected.