Colin O'Dell, as mentioned on his blog, has put together the instructions for something he calls "PHPUnicorn" (not to be confused with the PHP Unicorn conference) - a real-time system for visualizing unit test results via a Raspberry Pi, some LEDs and a Unicorn pHAT board.

A simple PHPUnit listener collects test results and sends them to a Raspberry Pi Zero Wireless device in real-time. As the device receives the stats it lights up LEDs green, red, or orange to visualize the progress and results of your unit tests.

The full instructions are over in this article on the Hackster.io site providing you with a list of the components needed, how you'll need to extend PHPUnit with a custom listener and a simple Python script to interface with the Pi and Unicorn board. The end result is a set of LEDs on the board showing the progress (and failures) of your unit tests being run.

In code reviews we often browse metrics, source code and reported code issues together with our customers. This leads to discussions about the current state of the code and possible improvements. First we used a bunch of shells scripts for that. In a second step we developed a simple PHP (Open Source) application helping us to do the job. Now we did the third step and rewrote that application into a React based client side (Open Source) application.

They start with an overview of why they created the tool (an evolution of the older Code Review tool) and why it was split into a frontend/backend model to provide easier pipeline integration. They then introduce the functionality in the new tool, based on a D3.js interface. A few screenshots of the interface are alsoincluded to give you an idea of how it reports its findings and the dashboard providing an overview of the findings. You can try it out by grabbing it from the project's GitHub repository.

We had been looking into code quality checking tools for a while here on SitePoint – most recently in a series on Jenkins, but none of those could do what a project I’ve only recently found out about can. PhpMetrics uses D3 and some sophisticated analysis algorithms to scan your application’s code and output intricate reports about it.

He walks you through the install (via Composer) and how to clone two example projects, Laravel and Symfony, to evaluate. He includes the command line to run the evaluation and plenty of screenshots showing the results for things like:

Cyclomatic complexity

Abstractness

Maintainability

Code density

He uses the results from these two projects in his examples and, at the end of the post, summarizes and compares the results it produced.

During some of his development, Christian Weiske found the tests for a project he was working on too slow for comfort and figured there had to be a way to find the root cause:

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.

On his blog Sebastian Bergmann has a recent post about how he's visualizing PHPUnit's development and pushing that information into a video based on the history of the project.

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.

Derick Rethans has been working on some updates to a tool he's developed, VLD, to make it more helpful and effecting in optimizing the opcodes in your scripts and find the dead opcodes and paths. He talks about these updates in this recent post.

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.

Raphael Stolt recently spent some time working up a tool to visualize Phing buildfiles and he's blogged about it in this new post.

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.

Felix Geisendorfer is taking an interesting approach to defining programming in this new post to the Debuggable blog - he's coming at it more from the level of the perception the programmer has about writing good code.

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.