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.
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
