He shows the results in execution time and memory used for PHP 5 versus PHP 7 versions, both with and without code coverage being generated. He also includes two examples of running the tests with PHP 7, once using the XDebug debugger and one using phpdbg.

PHPUnit 4.7 introduces a couple of small improvements. For instance, PHPUnit's PHPT test runner now supports --INI-- sections, information about the PHP runtime used is now printed in verbose mode, and a warning is now printed when code coverage data is collected but no whitelist is configured.

He also talks about the support that's been added improving the output of the HTML version of the code coverage reports, showing different colors based on how well covered the lines are. He also briefly looks ahead to PHPUnit 5, the versions it will support and the plans for release.

In his latest post Freek Lijten talks about PHP extensions, the upcoming PHP version - well, PHP7 - and the things that can be (and are being) done to help improve and prepare the extension ecosystem. In his post he walks you through the process of getting a PHP7 install set up, a sample extension set up and writing some tests to help improve it.

PHP7 is coming. And it is coming to a neighbourhood near you :) A couple of people started an initiative to ensure extensions will be running out of the box once PHP7 hits the shelves. The fun part: You can help too! No C knowledge is necessary (although it is fun to dive into PHP's internals!). This piece is a short intro to help you help PHP! Help triaging extensions, write tests, add documentation and who knows when you'll be diving into C code.

He's encouraging this work as a part of the recently launched GoPHP7 - Extensions initiative launched a while back. He starts by helping you get PHP7 installed (from source, compiled). Once that's installed and working, he helps you get an extension up and running, in this case the enchant extension. He shows you how to run the tests for the extension and how to write some tests to contribute back to the project. He includes instructions for generating code coverage reports, walks you through some sample code and a link to a page with more information if you get stuck.

In this recent post to his site Dave Marshall looks at a method for evaluating the overall quality of your suite of unit tests with help from mutation testing.

100% code coverage should never really be a goal. [...] I feel pursuing 100% coverage in a PHP project is a particularly poor idea as our tooling generally only provides Line Coverage. [...] There are more reasonable coverage metrics to use to measure the quality of a test suite. Sebastian Bergmann and Derick Rethans are working hard on bringing some of these options to us, but for now we're limited to line coverage.

He talks about the difference between line, branch and condition coverage types (with code examples) and which allows for more effective and quality tests to be written. He then talks about the results of an experiment to achieve 100% coverage on the Router component in the Aura project. He found the problem using mutation testing - changing values in the production code to make sure the tests break. He also links over to a new mutation testing tool that's been released to help with this kind of thing, humbug, and some of the results it can report.

Mutation testing is a great thing to have a grasp of in theory, but it's not particularly easy to practice. The tools are very hard to write and then their output is often hard to understand or interpret effectively. I wouldn't recommend practicing with mutation testing on a regular basis, but it's certainly worth considering on the odd occasion.

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.

Derick Rethans has posted the first in a series focusing on the Xdebug tool and the code coverage functionality it can provide via PHPUnit's testing. In this first post he catches the reader up on the current state of things and what all the Xdebug tool can do.

Since ages Xdebug has provided code coverage support for PHPUnit, a way to show which lines are covered by your test cases. But I never really wrote about how it works. A recently filed bug prompted me to write this post, as well as a follow up post on Code Coverage's future.

He starts off with the early days of Xdebug, how it hooked into the Zend Engine (that powers a lot of PHP behind the scenes) and when it was triggered. This came with its own set of problems so Xdebug was updated to overload some opcodes. He talks about how it can calculate the unused lines and determines which lines can be covered in the code coverage results. He provides some example code showing the execution of the coverage report on a simple function and try/catch handler, complete with the HTML output of the results.

NetTuts.com has kicked off a new series of posts today that answers the question "Why unit test?" The series, Unit Testing Succinctly aims to define what unit testing is, approaches to implementing them and what they can do to help you and your application.

The usual mantra we hear regarding any software methodology is that it improves usability and quality, reduces development and testing time, and brings the product to market faster and with fewer bugs. These are lofty goals, but I have yet to see a methodology deliver the Grail of software development. Ultimately, the primary reason to write unit tests is to prove correctness, and this happens only if you write unit tests well.

In this first post they cover three of the more general reasons for making the dive into unit testing your applications at all. These are more "business value" kinds of ideas but they trickle down into the development level, providing value for the developers too.

Measuring Correctness

Repetition, Repetition, Repetition

Code Coverage

Their main point to reinforce is the first of the three, though. Unit testing helps to measure and ensure correctness of both the code itself and the functionality it performs.

Rami Alnawas has posted an interesting tutorial for the Phalcon users out there showing one way you can unit test your models. It's based on his own experience with the framework in a current project.

My first contribution to the PHP community in general, and Phalcon folks in particular, was the introduction of MVC Functional Testing with PHPUnit, this meant that Applications developed using Phalcon Framework could be unit tested by requesting a url then asserting that the response is handled by a specific action within the controller. [...] To date, my latest addition is an example of how to unit test code that utilises Phalcon models, mainly the various static find methods. The code is available on github and the coverage report is coveralls.io.

He shows it at work, creating a simple "Popup" model and a facade to help with making instances for testing. He also includes the code to test this facade, checking the results of methods like "fetchall", "select" and "execute".

The latest version of the popular PHP unit testing tool PHPUnit has officially been released (version 4.0.0) and comes with some nice improvements. In this post to the PHPcc blog Sebastian Bergmann talks about enhancements in one area - code coverage reporting.

One of the highlights of PHPUnit 4.0, which was released last week, is an improvement of the @covers annotation and the addition of the @uses annotation for better code coverage analysis.

He includes a few simple code snippets showing you how the "@covers" annotation has been working and how it can be used in both strict and non-strict modes. He also introduces the "@uses" annotation to define which objects the test is using and how the two interact. He finishes off the post with a mention of the "--strict-coverage" command line flag (or the more general "--strict").

On the VGTech blog today Christer Edvartsen looks at a method of generating the code coverage of Behat tests using a special bit of code and the $_SERVER superglobal to detect what parts of the code is being executed.

Yes, I know, it sounds silly, but bear with me. The nature of acceptance tests is not really to tests units of code, but to assure that the behavior of your application meets a certain set of criteria (Behat Scenarios). When your applications grow over time, code coverage can be a nice tool to help you pinpoint where you need to add more tests. In a perfect world tests are added while implementing new features so that your applications are always fully tested, but that isn’t always as easy as it sounds.

The first chunk of code is something that would go in the router of your application, capturing the "collect coverage" and "enable coverage" input variables. The other part of the code creates a unique ID in the set up and uses it in a call (via Guzzle) to the server to start the tracking. In the tear down method, it sends the call to get the coverage results and process them through the PHP_CodeCoverage tool from Sebastian Bergmann.