Custom ArgsMatcher

[MartinMystikJonas]

New version of pull request #9 rebased to current master.

---

Default object args matching based on spl_object_hash is not practical in case of value object, which equality is based only on properties values. Custom argsMatchers can replace default argsMatcher to support different matching policy.

Example of CustomArgsMatcher we currently use:

class CustomArgsMatcher extends \Mockista\ArgsMatcher {

  protected function hashArg($arg) {
    if($arg instanceof Entity) {
      // entites are matched based on values of their properties
      return md5(print_r($arg->getProperties()->toArray(), true));
    } elseif($arg instanceof \DateTime) {
      //two DateTime objects are equivalent it they represent same time
      return md5(print_r($arg->format("Y-m-d_H:i:se")), true);
    } elseif($arg instanceof \Nette\ArrayHash) {
      // ArrayHash wrapper of array is matched based on it's content
      return parent::hashArg((array)$arg);
    } else {
      // fallback for all other types
      return parent::hashArg($arg);
    }
  }

}

Usage:

$registry = new \Mockista\Registry(new CustomArgsMatcher()); 
// all mocks created by registry will use CustomArgsMatcher

$mock = $registry->create();
$mock->setArgsMatcher(new CustomArgsMatcher());
// change argsMatcher only for specific mock

$date1 = new \DateTime("2014-05-23 10:00:00");
$date2 = new \DateTime("2014-05-23 10:00:00");
$mock->expects('method')->with($date1)->once();
$mock->method($date2);
$mock->assertExpectations();
// assert is valid if CustomArgsMatcher compare DateTime only by value

[janmarek]

I really don't think that custom args matcher should be set globally.

What about something like:

interface ArgsMatcher
{
    /** @return bool */
    match($arg);
}

class DateMatcher implements ArgsMatcher
{
    // ...
}

$mock->expect('method')->with(new DateMatcher("2014-05-23 10:00:00"))->once();

[MartinMystikJonas]

I think it is very practical to set it globally if you know that some types are value types you want always checked only by their value.

For value types you will need to remember to use custom matcher in every expect. If you forgot then you get brittle tests which will fail if you change implementation details (for example if you for some reason re-create value object instead of passsing it through).

Another common issue is if parameter is created inside object you testing and then passed as parameter in call to mock. In this case you cannot use identity matching, because instance is created somewhere else. But you want simple way how to test that passed argument has correct value.

Take for example DateTime. There is no situation in which you care what instance was used. All you care about is what time it represents.

This has to be used carefully but it will simplify lot of tests if you use value objects.

[MartinMystikJonas]

Basically this if workaround for missing equals() magic methods which we have for example in Java.

[f3l1x]

@MartinMystikJonas Hi. Is this ticket relevant ant this moment?

[MartinMystikJonas]

We still use this in our fork.