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.

On the Xebee blog there's a recent post looking at test-driven development with the Zend Framework and PHPUnit. They show how they work well together and make it simpler to use TTD to create and test your applications.

Over the past few days I was going through the Zend Framework reference docs and I found myself pleasantly surprised with all that the latest version of this web application framework provides. [...] Out of the many new features, what stood out for me was the ease with which Zend Framework and PHPUnit complement and work with each other.

He talks about some of the features of PHPUnit (including dependencies, testing for exceptions and errors) and how it fits into a good deployment strategy. He shows how you can use the Zend_Test component of the framework, along with the Zend_Test_PHPUnit features, to make a sample test case. There's also an example of using the Zend_Test_PHPUnit_Db component to test database information and your backend data stores to compare them to a formatted XML document.

In a new post to his blog Davey Shafik goes on a bit more about NetBeans which is quickly becoming his favorite IDE in the series of ones he's tried (including Zend's offering, Eclipse with PDT and his most recent choice NetBeans).

And let me tell you, Netbeans 6.8 is nothing short of amazing. Debugging with xdebug is now almost as easy as ZDE, it works instantly on 90% of my remote machines, but I have 1 cluster for which Netbeans simply *cannot* find the local source file, making it impossible to debug.

Watches, breakpoints (though, I haven't figured out conditional breakpoints, if they are there), callstack and local variables work as you would expect (though watches/variables sometimes refuse to populate larger vars, I think this is xdebug config related). In addition, Netbeans supports arbitrary breakpoint groupings; these can be enabled and disabled as a group - very neat.

He points out the excellent PHPUnit support the IDE has to offer and includes some screenshots of how you can run tests right inside the IDE, displaying code coverage information both at the file and line of code level.

On the Ibuildings techPortal today there's a new article from Lorna Mitchell looking at the phploc tool as a way to analyze your code and pick out a whole selection of statistics.

This has been a feature of PHPUnit for some time but has been released as a separate project in the phpunit pear channel. The nature of PHPUnit means that many of these statistics can be collected while the tests are running, which is why it was added to that tool in the first instance.

Stats gathered include the number of directories, files, interfaces, methods, functions and constants with more details for each (like visibility, actual lines of code contained in them and the cyclomatic complexity). The tool is very simple to use - just call it from the command like and give it a path to your codebase. It does the rest and spits out a text-based report.

Raphael Stolt has an interesting idea about PHPUnit plugin (GitHub_TicketListener) that allows you to close (or reopen) Github issues via PHPUnit tests.

Since PHPUnit 3.4.0 a new extension point for interacting with issue tracking systems [...]. The extension point has been introduced by an abstract PHPUnit_Extensions_TicketListener class, which allows developer to add tailor-made ticket listeners supporting their favoured TTS.

The "@ticket" notation that PHPUnit allows as an annotation is the key to linking together your unit tests with the new listener. Two methods, getTicketInfo and updateTicket, are used to have the listener make a cURL connection over to Github and send the request to a REST-like service on the remote side.

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 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.

Matthew Turland has put together a guide for getting PHPUnit and Xdebug up and working on one of the latest Ubuntu releases (Karmic) to resolve an upgrade issue with the package install.

This is just a quick post to advise anyone who may be using PHPUnit and Xdebug together on Ubuntu Karmic. If you try to upgrade to PHPUnit 3.4.6 and you're using the php5-xdebug Ubuntu package (which is Xdebug 2.0.4), you may get output that looks like [this error].

He gives a two ways to overcome the issue - forcing the PEAR installer to ignore dependencies or reinstalling with Xdebug 2.0.5 instead (via the PECL installer) as a shared module.