Derick Rethans has continued his series looking at the code coverage handling that XDebug and PHPUnit make available, allowing you to find the spots in your code not tested much easier. In this new post he talks about a new feature coming to the XDebug tool - branch and path coverage.

Picking up from where we left last time, in this second article we will look at some upcoming functionality in Xdebug. Sebastian has been pressuring me for years to add branch and path coverage to Xdebug, with issue #1034. In the post I will show you what "branch and path coverage" is, and how it helps.

How does this new type of coverage differ from the current functionality? Derick goes on to explain the difference via a simple example (and its resulting coverage). In the first example, using the XDebug available today, shows a fully tested function despite not all paths being testing correctly (a false coverage report). He gets into the "under the covers" changes he's made including how the opcodes are reported and changes he's made to the VLD to make it handle the branching smarter and make coverage more than just a "lines covered" metric. He shows an updated graph of the new coverage/branch flow and what a resulting coverage report might look like with the new "Paths" reporting.

In his latest post Derick Rethans talks about something that plagues every project, PHP or otherwise, after its grown to a large enough size: dead code. He's been asked why his Xdebug tool finds this code in places where people don't expect, so he figured he'd answer it once and for all.

The explanation for this is rather simple. Xdebug checks code coverage by adding hooks into certain opcodes. Opcodes are the building blocks of oparrays. PHP converts each element in your script - main body, method, function - to oparrays when it parses them. The PHP engine then executes those oparrays by running some code for each opcode. Opcodes are generated, but they are not optimised. Which means that it does not remove opcodes that can not be executed.

He gets down to the opcode level and shows some output from vld on how things are being executed (and what's not). Using a simple "foo" function example, he shows the execution flow and how the "branches" of executions work through the code. In his case, the "dead code" marker is coming from the line with a closing brace from an "if" statement. He points out that it entirely depends on the lines executed as to what is marked as "dead code".

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.

While working on an issue with debugging a script of his via XDebug, Derick Rethans was reminded of something that is an integral part of the PHP language - its two phase compiler.

During the first pass, it will find out to which opcode it needs to jump in the jump instructions. However, the PHP engine (and Xdebug) expects a memory address to jump to while executing your script. In the second pass, the compiler will then go over the generated opcodes and calculate the memory address to jump to from the jumps to opcode numbers.

Because of the way that XDebug was handling the checks (with the user-defined error handler) and how the opcodes inside of PHP are handled, the user-defined handler happened in between the first and second phases and the latter run couldn't find the resources it was looking for, thus the crash.

Derick Rethans has posted about new versions of two PHP extensions with "very distinctive purposes" - VLD and translit.

VLD is for the "hardcore hackers" out there to see what's happening behind the scenes for each request made to PHP and the translit extension makes it easier to "transliterate" information into other formats (with filters like "normalize_numbers" and converting text to Chinese).

You can grab the updated version through the standard pecl interface or from their pages on the PECL site.