Richard Bagshaw has a post to his site sharing some of his experience with the Prophecy testing tool and how it compares to Mockery for creating test doubles (mocks and stubs).

For a while now I have been using Mockery as my test double framework of choice, however recently I have been taking a look at Prophecy as an alternative.

[...] "Prophecy is a highly opinionated yet very powerful and flexible PHP object mocking framework. Though initially it was created to fulfil phpspec2 needs, it is flexible enough to be used inside any testing framework out there with minimal effort."

He then gets into some basic usage of the tool - creating a basic mock, assigning expectations and behaviors and performing the test. He steps through each line of the example explaining what's happening and what can be expected as a result. He ends the post with some final thoughts comparing Prophecy to the normal PHPUnit mocking tools and points out several other features it makes easier to work with as well.

On thePHP.cc blog today Sebastian Bergmann has posted about the new release of PHPUnit (4.5) and how it now comes with support for the Prophecy mocking tool.

PHPUnit has had built-in support for creating test doubles for many years. This implementation was originally inspired by the first generation of mocking frameworks for Java. Since then mocking frameworks have evolved. Modern mocking frameworks are more intuitive to use, lead to more readable code, and may even allow for a clear separation of a test double's configuration and the actual test double object itself.

Like many users of PHPUnit I am not satisfied with the API of PHPUnit's own mocking framework. This dissatisfaction has lead to the development of alternative mocking frameworks for PHP such as Mockery, Phake, or Prophecy. If I were to create a new mocking framework today it would probably look a lot like Prophecy. Which is why PHPUnit 4.5 introduced out-of-the-box support for it.

He gets into some of the basics of the Prophecy tool and how it handles mocking differently than the current internal mocking PHPUnit provides. Some code examples are included showing dummies, stubs and mocks with an example of the output when some of the "predictions" have failed.

In a new post to his site today Konstantin Kudryashov takes a look at two PHP testing tools and the differences/similarities between them - Mockery and Prophecy. Mockery is a mocking tool created by Pádraic Brady to make mocking simpler and Prophecy is more of a mocking framework, both for use in PHP unit testing.

Today I’ve been asked twice what’s the difference between Mockery and Prophecy just to suddenly discover that I didn’t clarify this aspect never before. Well, that’s about time. If we were to remove all the syntactical and implementation differences between two libraries what we’ll be left with is one really big conceptual difference and it’s the fact that in contradiction to Mockery, Prophecy puts messaging (aka how objects communicate) before structure (aka when objects communicate).

He starts with a sample class (the usual "calculator" example) and shows how it would look to mock it out with each tool, setting return values for both the "getRating" and "setRating" methods. He enhances the tests a bit more to include an event dispatcher and raising an event. The approach is similar, but Prophecy uses something called "message binding" to more effectively handle changes to the class under test.

The Inviqa techPortal has a new post today from Marcello Duarte about using Prophecy in unit testing to work with mocks and doubles.

Test doubles are a way of replacing all classes in our tests other than the one we are testing. They give us control on direct and indirect outputs that would have been generated by those classes. Understanding the role of the test double helps us to write better tests, and thus better code. [...] When writing unit tests we are focusing on describing one unit of behaviour at a time, and how objects communicate in order to achieve that behaviour. We instantiate the object under test, call a method of the object and observe if the outcome is as expected.

In his examples he uses Prophecy to mock out different kinds of objects - a dummy object, a "fake" (with listeners for other object calls), a stub that mocks other internal method calls and a more familiar mock object. He also talks about two guidelines to follow when thinking about writing tests and code complexity - the Law of Demeter and "Don't Mock What You Don't Own." He gives an example of working around this last one by using the Adapter design pattern.