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.