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.

Sebastian Bergmann has written up a post for his blog recently that looks at unit testing singletons, something that's been rumored as being some of the hardest to test.

I frequently quote Miško Hevery with "It is hard to test code that uses singletons." And then my audience asks me... Why is it hard to test code that uses singletons? Lets have a look at the default implementation of the Singleton design pattern in PHP.

He defines a singleton first, showing how it's used to create single instances of objects and, because of this, cannot be tested easily because there's no way to know you're getting a clean instance every time. Dependency injection can help with the problem by allowing you to pass in a "mock" instance of the singleton class each time. He also mentions some variations on singletons that could make it easier to test in the future.

On the Blue Parabola blog today there's a look at working with the Zend_Test component of the Zend Framework (from Matthew Turland).

I went to the "tests" directory generated for me by the zf CLI utility to get started. What I found there was three files: application/bootstrap.php, library/bootstrap.php, phpunit.xml They were all completely empty, which didn't really provide much in the way of guidance on how to get started. The Zend_Test documentation is good, but was a bit lacking in that area as well; it really only covers how Zend_Test extends the capabilities of PHPUnit.

Matthew walks you through his process of creating a sample PHPUnit XML configuration file (with a little help), updating your bootstrap to load in paths to the test files and the creation of a sample test case for a MySQL database. He runs a test on the database to compare it to a standardized data set based on an XML file (seed.xml). He also looks briefly at testing controllers, some sample code included for this as well.

As Sebastian Bergmann mentions in his latest post, he's changed up how the code coverage functionality is handled in PHPUnit so that he can add something new - CRAP.

PHP_CodeCoverage is a component that provides collection, processing, and rendering functionality for PHP code coverage information. [...] Having all code that deals with code coverage in a separate component allows for easier development and better testing. The first result of these improved development conditions is a small new feature that I recently implemented, the support for the CRAP metric.

Your code's CRAP (Change Risk Analysis and Predictions) scoring combines the idea of cyclomatic complexity and code coverage statistics to try to guess at how difficult any given piece of code would be to maintain. You can see an example here - the lower the number the better.

In this recent post to his blog Johannes Schluter talks about a method he's suggested for testing objects in unit tests - overriding the "new" operator to replace specific classes with mocks.

Two years ago at some conference I had a conversation with Sebastian about the need for a way to overload the new operator in PHP so, probably, bad designed code can be tested more easily by replacing specific classes with mocks. [...] Sebastian then pushed the code as part of a new test_helpers extension with some documentation to github and I fixed some bugs in it. The aim of the extension is to collect functionality which might be beneficial for phpUnit and other test scenarios but which should never reach a production environment.

He includes some sample code to show it in action - defining the mock class, using the set_new_overload function to define it as what should be called when the "new" operator is used and a dump of the result.

In a new post to his blog Matthew Turland looks at a contribution he recently made to the PHPunit project to help it support database testing without the need for dumping the contents of your database out to a CSV.

If you're using MySQL as your database, CSV has been the only format supported by both the mysqldump utility and the PHPUnit Database extension up to this point. My contribution adds support for its XML format to the extension. While this support was developed to work in the PHPUnit 3.4.x branch, it won't be available in a stable release until 3.5.0. In the meantime, this is how you can use it now.

There's four steps you'll need to do to get it installed - grab the latest from github, create the seed data XML file, make a test case extending PHPUnit_Extensions_Database_TestCase and run your tests against the database information.

On his blog today Sameer Borate has posted a method for creating test dependencies in your PHPUnit tests on your application.

PHPUnit 3.4 now supports dependencies between different test methods. It allows you to execute a particular test ONLY IF the test that it depends on executes successfully (using a linked-list class.

He starts off with a simple tests and breaks it up into two different pieces - one to test the creation of the list and another to test the linking of the list. By using the "@depends" notation in the comments of the linking test, you can tell PHPUnit to link the two and only pass if both do. He also touches on Producers and Consumers in testing.

If you already have a set of unit tests (PHPUnit) and are thinking of implementing a build tool like Phing, you might want to check out this new post from Giorgio Sironi about combining the two with a simple addition to your build configuration.

Integrating these two tools means giving Phing access to a PHPUnit test suite and letting the Phing build files, which manage configuration, contain also information on how to run the test suite. In the build.xml file of an application you should find different targets like generate-documentation, test-all, compile-all (if php were a compiled language), and so on.

He mentions the two ways you can run your unit tests - one being more native (a phpunit task) and the other a bit more "blind" (exec task). He looks at the first, allowing tighter integration with Phing and can actually break the build if something fails. He includes the XML for both to include in the build file and a brief explanation of what they're doing behind the scenes.

Giorgio Sironi has a new post talking about his upcoming eBook for all of those interesting in testing PHP applications - "Practical PHP Testing (Don't Let Your PHP be Eaten Alive)".

This publication focuses on testing and designing php code, with the aid of the leading tool for test automation, PHPUnit. Testing is a skill which is often neglected by php developers, but testable code inherit many benefits of the good design rules it is forced to observe.

The book will include the content of his testing series of posts, code examples, a glossary of commonly used terms and several Test-Driven Development exercises in each chapter. He looking to have it published during the beginning of December and will be released under a Creative Commons license. Here's a sneak peek at the cover.