Jakub Zalas has a recent post to his blog with a hint about how to test Symfony container services by mocking them (when testing with Behat) with the help of Mockery (and the PSSMockeryBundle).

Mocking objects in unit tests is pretty straightforward as every object used in a test case is usually created in a scope of one test class. In functional tests it's a bit harder since we either don't have full control over objects being created or it's simply too laborious to mock half the framework. [...] We're getting the service from a container [in the example] and calling a method which should send a lead. The problem is we don't want to actually call an API while executing Behat scenarios.

Rather than hitting up the API for each test, he opts to create mock objects and results with the tools Mockery has to offer. He gives code for a "is API available" method that either returns a valid container or a mocked object, depending on how it was called.

Kurt Payne has a new post to his blog showing how you can unit test your process forking in your PHP application (pcntl).

At some point, many php developers turn to the pcntl functions in php to write a daemon, or server, or simulate threading. But how do you unit test this with complete code coverage? [...] We need to engage some black arts php extensions to make this happen. An installation guide follows, and the post ends with a complete listing of the unit test.

He uses the test_helpers extension (as provided by Sebastian Bergmann) and Runkit to allow the test to define new methods copying the current pcntl methods and mocks up the responses. Tests are included to check the parent of a process, checking the children of a process and testing that a fork could be made. Hes's even included visual proof of this working.

On the VG Tech blog today there's another post related to unit testing (here's one from before) but this time they're talking about mocking the filesystem with vfsStream, a powerful tool that lets you interact with PHP streams as a virtual file system.

This article is about how to mock the file system when writing unit tests, and it will be rather code-heavy. [...] PHPUnit is the de-facto standard for unit testing in PHP projects, and this is what we will be using together with vfsStream in this article.

The include the code for a simple storage driver (VGF_Storage_Driver_Filesystem) to use with vfsStream with "store", "delete" and "get" methods. Also included are examples of using vfsStream to check things like directory existence, if a file exists, or if a file can be read. A few simple assertions are set up in their sample test to check the methods in their "VGF_Storage_Driver_Filesystem" class.

On the VG Tech blog today there's a new post from André Roaldseth about using PHPUnit to test PHP streams, basing the assertions on the data rather than the functionality itself.

Using the memory/temporary stream provided by php:// stream wrapper you can create a stream with read and write access directly to RAM or to a temporary file [using "php://memory"]. This gives you the possibilty to write unit tests that does not rely on a specific file, resource or stream, but rather on data provided by the test itself.

There's no specific code examples here, but you can refer to the stream wrappers section of the PHP manual for more details on this and other handy built-in streams. Once created, it can then be used just as any other stream resource can. This could be useful to provide mocks in your testing, replacing any other stream-able resource with a "memory" or "temp" placeholder.

Wojciech Sznapka has a new post today sharing his opinions as to why Mockery is better than PHPUnit Mock Builder in testing Symfony2-based applications.

Recently I did a lot of Test Driven Development on my Symfony2 bundle. I used PHPUnit's built-in mocks and stubs for many projects, so I took it again. But while I was working on mocking Symfony2 core objects I found those mocks very uncomfortable in use. I tried Mockery and it saved my day. Let's see how to get it working with Symfony2 and how it kicks ass!

He shows how to get things set up - adding Mockery to the dependencies file (deps), getting the latest version from their git repository and an example mock method that shows the difference in mocking the Doctrine2 entity manager - PHPUnit vs Mockery.

Lars Tesmer has a suggestion for all of the unit testers out there (you do unit test your code, right?) when needing to test a piece of code that makes a call to something on the file system or a remote resource. Their examples come from tests written against the Assetic codebase.

For our most recent After Work Hacking my co-workers and me decided to write unit tests for the open source project Assetic. That turned out to be a better decision than our last one, yet we still ran into an interesting challenge.

In testing the HttpAsset class from the tool, they came across the problem - a call to a remote/file resource that could not be tested because of a file_get_contents call that depends on an external source. They came up with a few options to try to test this example, some better than others:

• Give it a real URL to test with
• Wrap the file_get_contents inside of a new class (ex. a "ContentFetcher")
• Use vfsStream to mock out the file system in the unit test

In their case, vfsStream couldn't be used due to how the fetch call was made, but the tool can be very handy if you need to mock out an external file system resource.

Till Klampaeckel has a new post to his blog today looking at the method he's found (through some help from others) to be able to mock out protected methods in his unit tests.

I wrote a couple tests for a small CouchDB access wrapper today. But when I wrote the implementation itself, I realized that my class setup depends on an actual CouchDB server being available and here my journey began.

It was his first experience trying to mock out parts of a class, and he found it a bit difficult to use even after reading this article from Sebastian Bergmann. He ended up, as a first solution, making a "fake" (a term from Ruby testing) that just returned the basic JSON string of an error. Thanks to comments on the post, though, he was able to come up with a more correct solution using getMock() to create a stub and apply an expects() to his "makeRequest" method.

On the Web Builder Zone (a part of DZone.com) there's a recent post from Giorgio Sironi reviewing the Mockery library, a mock object framework created by Padraic Brady.

Mockery is a mock object framework (more properly Test Double framework) from @padraicb, independent from testing frameworks like PHPUnit. It can be used to quickly prepare Mocks, Stubs and other Test Doubles to use inside your unit tests. I've tried Mockery via a PEAR installation and I must say its expressive power is higher than that of PHPUnit mocking system. However, it may be too powerful for effective usage.

He talks about some of the features that are in Mockery that aren't in PHPUnit like alternative expectations, recording of the expected calls and the mocking of non-existent methods. He notes that it can be too overwhelming at times, though, with so many features that may or may not be useful for the large majority of testers. He includes some sample code showing a set of five tests on a simple class implementing an interface.

In a recent post to his blog Fabian Schmengler looks at mocking something in your unit tests that could cause problems in certain situations - needing a specific kind of response from a built-in PHP function. In his case, he shows how to mock time to return the same formatted date.

A common problem in Unit Testing in PHP is testing something that depends on the current time. For a determined test it should be possible to set the time in your test script without really changing the system settings. In this article I'll describe how it is usually done with OOP and then come to an alternative solution with much less code that makes use of the new features in PHP 5.3.

He shows a usual approach using dependency injection and a class wrapper to handle the set and fetch of the date value. His alternative uses namespacing to redefine the internal PHP function into something custom. Then, when the test is executed, it can use that custom namespace's version, overriding the default. It's a pretty seamless option and can save you a good bit of time and hassle with other classes each time you need to customize the results.

Mike Lively has a new post about a PEAR channel he's set up for his Phake mocking tool on his digitalsandwich.com domain.

For those that may not have caught my first post on the subject, Phake is a mock framework that I announced a couple of days ago in Introducing Phake Mocking Framework. It was recommended in the comments that I get it on a pear channel somewhere, which is something I have wanted to do but hadn't had a reason to do until this week. Well, now there is an official Digital Sandwich Pear Channel that is hosting Phake.

Discover the channel with the PEAR installer and run the install with the path provided. He notes that the release is alpha because of the lack of documentation but, despite this, the API is stable. Also, you'll need to be using PHP 5.2+ to use the tool.