Usually you just don't test or mock the private & protected methods directy.
What you want to test is the public API of your class. Everything else is an implementation detail for your class and should not "break" your tests if you change it.
That also helps you when you notice that you "can't get 100% code coverage" because you might have code in your class that you can't execute by calling the public API.
You usually don't want to do this
But if your class looks like this:
class a {
public function b() {
return 5 + $this->c();
}
private function c() {
return mt_rand(1,3);
}
}
i can see the need to want to mock out c() since the "random" function is global state and you can't test that.
The "clean?/verbose?/overcomplicated-maybe?/i-like-it-usually" Solution
class a {
public function __construct(RandomGenerator $foo) {
$this->foo = $foo;
}
public function b() {
return 5 + $this->c();
}
private function c() {
return $this->foo->rand(1,3);
}
}
now there is no more need to mock "c()" out since it does not contain any globals and you can test nicely.
If you don't want to do or can't remove the global state from your private function (bad thing bad reality or you definition of bad might be different) that you can test against the mock.
// maybe set the function protected for this to work
$testMe = $this->getMock("a", array("c"));
$testMe->expects($this->once())->method("c")->will($this->returnValue(123123));
and run your tests against this mock since the only function you take out/mock is "c()".
To quote the "Pragmatic Unit Testing" book:
"In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out."
Some more: Why you don't want test private methods.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…