Adam Wathan has a recent post to his site showing you how to stub out your Eloquent relations in a Laravel application for use in your testing (rather than hitting the database directly).

When you’re trying to test methods on an Eloquent model, you often need to hit the database to really test your code.

But sometimes the functionality you’re testing doesn’t really depend on database features. Is there any way to test that stuff without hitting the database?

He starts with a look at the more traditional method, using the models normally and testing with the database. He includes a simple test and class showing a basic "song duration" integer response. He gets into a bit more detail on how the Eloquent code grabs the data it needs when a relation is accessed (hint: not a separate query) and how to update the test to mimic the eager loading of the duration information. He ends the post by pointing out that "nothing is free" however as, if the underlying database implementation changes, the test would start to fail regardless of it not using the database.

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.

Federico Cargnelutti has a helpful post to his site today for the unit testing/TDD crowd about checking the retuned value from a stub of an object in your tests. He's using the built-in mocking framework here, not something like Mockery.

State verification is used to ensure that after a method is run, the returned value of the SUT is as expected. Of course, you may need to use Stubs on a test double or a real object to tell the object to return a value in response to a given message. [...] In PHP, for example, you dynamically type the return value within the body of the method. This means that PHP mocking libraries cannot check the type of the return value and provide guarantees about what is being verified. This leads to the awkward situation where a refactoring may change the SUT behaviour and leave a stub broken but with passing tests.

He gives an example of a few classes - a Presenter and Collaborator - and a test that mocks out the Collaborator instance, calling a "getStories" method on it. He shows a situation where all tests pass in the initial version, but after some changes to the return type, a test that should fail doesn't. His solution for the issue revolves around DocBlock annotations and the Return Value instead of the built-in mock object return method.

Phil Bennett has a new post today talking about a way that you could use dependency injection in your testing, making it easier to work your system by using stubs, fakes and mocks.

Dependency injection is a simple design pattern that provides several benefits, one of which is the ability to vastly improve your unit test suite. In this post I am going to be looking at how this is done and how it relates to certain testing methodologies.

He talks some about the refactoring of an application to allow for easier dependency injection and how, while easier, can still make it difficult to abstract out things like database functionality. Instead, he suggests creating "fake" classes that model the behavior of the needed dependency. He shows examples of each type - a fake, stub and mock - and talks some about the differences between each (and situations one might be used over the other).

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.

On DZone.com today Giorgio Sironi has posted a "cheat sheet" to help you correlate the functionality of two PHP unit testing tools - PHPUnit vs Phake (for mocking objects).

Benjamin Eberlei introduced me to Phake with his recent article: it is a Composer-ready PHP library that integrates easily with PHPUnit and provides an independent Test Doubles framework, capable of producing Stubs, Mocks, and Spies. The syntax and object model reminds me of Mockito, the Java Test Double framework from the authors of Growing Object-Oriented Software. I like tools that do one thing and do it well, and after experimenting with Phake I'm using it on all new code.

He compares the two tools on a few different pieces of functionality including creating stubs, mocks and spies. Sample code is included for both sides. It's not a detailed guide by any means, but it can give you a better picture of how the two compare.

On the ZendCasts.com site there's a new screencast posted looking at autoloading in phar, the packaging tool built into PHP. This is a continuation of the series started here.

Building on the foundation from the previous screencast, he shows how to enhance it and allow it to autoload based on an autoloader defined in a "stub.php" file.

You can grab the complete source for this screencast over on github.

Sebastian Bergmann has a new post to his blog (part of a series on testing techniques for testing that difficult code) about the hard-coded dependencies required by your code and how to stub them for easier testing.

A mock object can be used anywhere in the program where the program expects an object of the mocked class. However, this only works as long as the object can be passed into the context where the original object is used.

Ideally this wouldn't be a problem - handled correctly, dependency injection would make it a non-issue. But, because it has been known to happen, PHPUnit gives you the ability, via the set_new_overload method, to capture that object definition and mock it with a reference to another method in the test class.

Sebastian Bergmann has two recent posts dealing with some of the more difficult topics in unit testing. One looks at sharing fixtures between tests and the other talks about stubbing and mocking static methods in your tests.

From the first of the two tutorials:

A good example of a fixture that makes sense to share across several tests is a database connection: you log into the database once and reuse the database connection instead of creating a new connection for each test. This makes your tests run faster.

This fixture sharing example uses the setUpBeforeClass and tearDownAfterClass methods to create and destroy the connection.

In the second article Sebastian shows how to mock up a sample static function and mock it with the "staticExpects" helper.