Hi Platonides, On Tue, Jul 03, 2012 at 12:40:35AM +0200, Platonides wrote: > On 01/07/12 13:49, Christian Aistleitner wrote: > > But as I said, one would mock /above/ the SQL layer. > > I was thinking on it. Some operations are "easy", insert a field, select > a field, you can perform the joins in php.
Yes.
> But you also need table schema knowledge.
Yes, obviously.
But this sounds more severe than it actually is. And regardless of
whether we use a mock or a real database, this coupling of schema and
tests is pretty much inevitable, once we decide to stop labelling our
“PHP-wide database integration tests” as “unit tests” and start to
additionally implement real unit tests ;-)
Note that changes in the database schema are not much of an issue
anyways. In 2012, there have been no major schema changes and only two
minimal ones [1]. The situation is alike when looking further back in
time.
Compare it to changing the method names on dependent objects. You'd
also have to reflect such changes in tests.
However, the main remaining hurdle is somewhere else: It's the
somewhat tight coupling of business objects. So when mocking the
database, it may be worthwhile to decouple objects along the way
bottom up to keep the effort manageable.
Kind regards,
Christian
[1] Adding job_timestamp column, and adding ipb_parent_block_id column.
--
---- 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
