The problem you are facing is due to the intersection of practices built on differing philosophical design assumptions so let me begin by setting some background of what those philosophies are.
[indent]The Duck Typing Philosophy
Don’t declare any interfaces, use any type hints, or check the types of anything. Anything goes! Occasionally you may wish to test if method_exists() to tell the difference between things.
[indent]
No boilerplate
Very flexible
No machine verification whether you are doing anything correct; you’re on your own Jim[/indent]
The Concrete Typing Philosophy
Use type hints to make sure you are getting the exact right things, no interfaces required.
[indent] No boilerplate
Machine verifies you’re doing the right thing all the time
Very inflexible[/indent]
Type to Interfaces Philosophy
Type hint a lot but only ever to interfaces. Make pretty much all your classes implement interfaces.
[indent] Very flexible
Lots of machine verification
Lots of boilerplate (interface declarations)[/indent]
Hybrid Philosophy
Combination of the above based on perceived needs at the time.
[indent] Only some of the boilerplate of Type to Interfaces
But only some of the protection
Get flexibility where you need it
Have to spend time thinking about which philosophy is appropriate
How do you know if you are going to need protection? I mean, you should always be writing correct code, right?
How do you know where you are going to need flexibility? Sure, you can guess but who really knows[/indent][/indent]
OK, back to the main event. The problem you are having is the mocking relies on flexibility being a fundamental trait of your design philosophy. I think this is good because flexibility is probably the most important thing. (Hence all this stuff about TDD helping you to create better designs and stuff.) So if you agree with that I hope you will also agree concrete typing (the philosophy used by this particular model you want to test) is the worst philosophy. It’s something you do because you can’t be bothered to declare an interface right now with on the understanding that you aren’t going to leave it like that and you sure as hell aren’t going to subject it to someone else.
Also, did you realize that constructors actually limit flexibility? A constructor is a special thing designed to control the creation of an object so that it can’t be put into an inconsistent state. The cost of this is that you lose the ability to say how you would like the object to be constructed. So this is another instance of the classic safety vs. flexibility problem. The traditional solution, or should I say the solution that came out of C++, is the factory: push the construction behavior up into another object and then we can always create other forms of construction. Smalltalk however had a much lighter weight solution: allow more than one constructor.
You can do this in PHP by not declaring __construct() and instead using static methods to construct your classes:
class Animal {
static function Dog() { return self::base('Dog', 'woof!'); }
static function Cow() { return self::base('Cow', 'moooo!'); }
static function Base($species, $snd) {
$o = new self;
$o->species = $species;
$o->snd = $snd; }
function describeYourself() {
return 'I am a ' . $this->species . ' and I go ' . $this->snd; }
static function SamuelLJackson() {
return self::base('bad-ass mother****er', '"get your dirty hands off me!"'); } }
(I like to begin them with an uppercase to indicate that they are constructors as opposed to some other static method.) If that was the technique used in your model class you could simply declare an alternate constructor and you’d be fine.
None of this is perfect however. I always felt like OO suffered from this problem of having to choose between lots of boilerplate, nailing everything down real inflexible like, or doing nothing just risking yo ass that everything has been done correctly. Of course the second you try to do anything on any kind of scale the boilerplate becomes the only sane choice. The real solution is to remove the statefulness and dependency on names as a means of connection intrinsic to OO. This is pretty much what pure functional programming (PFP) does but that moves you into a radically different style of programming. For instance you wouldn’t even have mocking in PFP because you don’t have things talking to one another through methods, you only have values being passed in and out of functions. You could think of this as classes each with exactly one method always called doIt() or something.
In the case that you can’t change this model you want to test at all then you could use vectorialpx’s solution. The downside to that is that you may need to copy over behavior that is in the constructor. That sort of bypasses the point of mocking with regards to the constructor but that’s not a big point. The other solution is to use eval. Yep. Generate a subclass of the class that in the type hint and have all the required methods point directly to an internal mock instance. Some mock libraries may even do this for you. I’m not familiar with PHPUnit, I always used SimpleTest.