Running the specific test cases for the part of the application you're working on is easy and fast, but that does not tell you when changes in part A of the app break part B - which happened several times, and all just because I didn't want to wait 45 seconds again and again. So a solution was badly needed; tests should be as fast as possible; preferably < 10 seconds. Before being able to make the slow tests faster, I had to find out which of the 80 tests were slow.

Tools like Jenkinks give more detail on test runs, but a normal PHPUnit install won't. So, he came up with a method that uses Phing's phpunitreport task to generate extra reporting easily. Here's some example screenshots: test results summary, test detail and single page views of the same sort of data.

According to svn.php.net, I committed the first PHPUnit code to cvs.php.net on November 27th 2001 and the first release, PHPUnit 0.1, was made on December 1st 2001. [...] On December 26th 2009, I moved the development of PHPUnit from svn.phpunit.de to GitHub. I imported the history from Subversion into Git. As you can see in the video, moving to GitHub lead to an increased number of contributions to PHPUnit.

You can watch the video either embedded in his post or directly from Vimeo. It's interesting to watch the progress of the application and see the contributions make to each of the parts. The whole video, spanning the entire commit history of the tool, lasts about 25 minutes.

Recently I've been working on some new functionality to visualise all the code paths that make up each function. These new routines sit on top of the routines that do dead code analysis. These new routines sit on top of the routines that do dead code analysis. Every branch instruction (such as if, but also for and foreach) is analysed and a list of branches is created. [...] Once all the branches and their links are found, another algorithm runs to figure out which paths can be created out of all the branches.

He illustrates with a few examples, showing both the command that was executed and the resulting output with the new path information of a simple test file using a "for" loop and an "if/else" conditional.

Out of the box the Phing -l option can be used to get a first overview of all available targets in a given buildfile but it doesn't untangle the target dependencies and sometimes a picture is still worth a thousand words. Luckily the Ant community already provides several tools to accomplish the visualization of Ant buildfiles, reaching from solutions that apply a Xslt stylesheet upon a given buildfile.

Using the ant2dot tool along with the Graphiz graphic library, he transforms the XML from the build file into a simple graphic showing the flow of the build. An example image is included.

I believe understanding the patterns in your own thinking will by far make the biggest impact on how good you will get as a programmer. Forget design patterns, forget unit testing, forget all those functions you know. Important is to question why they exist and how they could be improved.

He illustrates through a few examples what he means. He describes one such thought method, the "return home early" process - basically, if something looks too complex for its own good, it probably is. He offers a different way of thinking about it too, a more visual way that can help simplify things even more by laying out the pieces and seeing where they all fit.

I wrote this xslt stylesheet to visualize the parse tree of a PHP source code. The stylesheet can actually convert any XML tree to graph in the dot format interpreted by Graphviz.

His code is a simple seven line script that outputs a nice, clean tree structure image of how the process flows. He includes links to all of the source and files he used to create the tree image.

A long-standing feature request for PHPUnit has been the generation of a real diff between strings that span multiple lines.

Ideally this would be done by implementing the diff algorithm in PHP. But since Derick needed a working solution quickly, the two of us came up with a "hack": we just use GNU diff and invoke the diff command via shell_exec().

He gives an example, showing how to judge the difference between two strings of HTML in a test. The result catches the differences (inside the body tags) easily.