In phpunit we can specify the method was called with particular
->with($this->equalTo('foobar'))
or any
->with($this->anything())
parameter.
But is there a way to specify that the method has been called without parameters at all?
This is the test I expect to fail:
public function testZ()
{
$a = $this->getMock('q');
$a->expects($this->once())
->method('z')
->with(); // <--- what constraint to specify here?
$a->z(1);
}
UPD:
The question has theoretical nature, so I have no any real life example. Some case it could be useful I can think of right now is:
public function testMe($object)
{
$object->foo();
}
And let’s assume that testMe should (by design and by requirements) always call the method without parameters (assuming foo() has default ones). Because any non-default parameter (more precise: any parameter != to default one, which we don’t know yet and which probably could change independently) in this case causes fatal consequences.
While rdlowrey is correct that
with()doesn’t make provisions for checking for no arguments passed, the problem doesn’t lie with PHPUnit but PHP itself.First, if your method doesn’t provide default values, the interpreter will raise a fatal error if you don’t pass any parameters. This is expected and not entirely relevant to the question at hand, but it’s important to state up front.
Second, if your method does provide default values, calling the method without arguments will cause PHP to alter the call before PHPUnit gets involved to pass the defaults instead. Here’s a simple test that demonstrates PHP inserting itself before PHP can check the parameters. It’s key to realize that the mock class that PHP creates has the same signature as the mocked class–including the defaults.
This means you can verify that either nothing was passed or the default values were passed, but you cannot be more specific.
Can you get around this limitation? You can remove default values from arguments when overriding methods, so you should be able to create a subclass and mock it. Is it worth it? My initial gut reaction is that this is a huge code smell. Either your design or your tests are doing the Wrong Thing(tm).
If you can provide a real-world, concrete example where you actually need to do this kind of test, it’s worth spending some time pondering a solution. Until then, I’m satisfied with the purely academic answer of “don’t do that.” 🙂