I’d like to add to this flaw another bad pattern that I’ve seen in PHP code. In PHP you can write code in the global scope and not just in function and method bodies. When you use PHPUnit, every time a file that has this kind of global code, it runs when a test includes the file or when the coverage report’s collector includes it. That means that possibly global state gets modified, and even strange errors may occur. Maybe the file just wants to include another file that is not on the include_path when the tests run, because the tests run from a directory and the file assumes that it will be run from another directory. So generally you at first make sure that this kind of code in the global scope will never ever get included (and I’ve seen codebases where it’s really hard to filter them) and at second you should ensure that this kind of code is kept to a minimum, like for entry points of your webapp (index.php and the others) and every other logic is in method (or at least function) bodies.
Basically it’s the same problem that arises when you use static initialization blocks in java (which you already bashed to death somewhere else ).

That’s my two cents on this. Keep up the good evangelizing

I can agree with guys who proposed using some stubs/mocks to pass to House constructor.
I would do the same in this case ( using DI would be even better) but in my triangle scenario it is not about collaborators validation
but validating internal consistency of object.

I am wondering what’s your opinion about checking invariants in constructor.
Let’s say you want to create triangle object, feeding it’s constructor with degrees of 3 angles.

Triangle(int angle1, int angle2, int angle3)

For triangle all interior angles total to 180 degrees.
Since I truly believe that objects should be responsible for ensuring validity of its state, checking if sum of user provided angles equals to 180 should be done in constructor – you would end up having some conditional logic in your constructor…

If invariant is violated i would throw IllegalArgumentException…

This approach seems to be very attractive – you will always work with valid triangles, but it kills testability:
To test any of triangle behavior (for example checking if triangle is right-angled) you first need to instantiate it feeding it with correct angle values.
For triangle example it does not seem to be the case, but in more complex scenarios instantiating object to be tested can be quite hard – not because of its hard coded collaborators but because of its invariants.

Thanks,
Bill