On his blog Marc Baker about static calls and the trouble they bring in your applications. It's a continuation of ideas that Kore Nordmann shared previously on his site.

It’s been seven years since Kore Nordmann first published “static considered harmful” on his blog, explaining the problems with using static method calls in classes, and the difficulties that they cause when trying to test that class. Seven years on, and those difficulties are still the same, and there is still new code being written using static calls despite that knowledge; but it’s often a more severe problem in legacy code with little or no unit tests.a

So why exactly are static calls so bad? If you’ve read Kore’s article, then you probably have a good idea already; but what that article doesn’t cover is approaches that we can use to make the code testable.

He covers the main issue static methods have when it comes to testing: they introduce coupling by hard-coding a dependency into your code. He talks about the static testing functionality that various PHP testing tools provided: PHPUnit, Phake and Mockery. He then focuses on a newer tool that he's discovered to help make the testing simpler: AspectMock. He gives an example of it in use and some examples of tests using anonymous classes to make it easier to create tests on the fly.

The Laravel News site has a tutorial posted that approaches a common development task - writing tests - from a data-driven approach rather than a strictly functional one.

Testing your code is an essential part of the development process, but sometimes it could also be expensive when you try to emulate many uses cases based on a set of different input data.

In many cases, you could end up with a massive directory of tests repeating the same block of code over and over for each possible user interaction.

They start with an example of a feature to test (Markdown parsing) and how traditional testing would have methods for each of the transformations. With a data-driven approach they turn the tests around and make use of data providers to set up the initial string, transformer to use and the correct result. Code is included showing an example of this kind of testing for the same Markdown parsing example and what a failure would look like in a dataset with multiple items.

In a new post to his site Matthias Noback has a post showing you how to, when using the Behat functional testing framework, to create local and remote code coverage metrics.

PHPUnit has built-in several options for generating code coverage data and reports. Behat doesn't. As Konstantin Kudryashov (@everzet) points out in an issue asking for code coverage options in Behat: "Code coverage is controversial idea and code coverage for StoryBDD framework is just nonsense. If you're doing code testing with StoryBDD - you're doing it wrong."

He starts off by talking about code coverage and why you might want it for the tests created through Behat. Code coverage metrics are usually associated with unit tests but having those numbers for the functional tests can be helpful too. He then covers the two pieces of the puzzle needed to gather the coverage numbers: an extension for the local coverage and one for the remote coverage. He shows how to get both of these installed, configured and used in the code to gather the results. Finally he shows how to use the phpcov tool to merge these results with the PHPUnit results to get a better overall view of coverage numbers.

Anna Filina has a quick post to her site with some recommendations around testing legacy PHP scripts giving an example of a challenge to test a controller in isolation from the rest of the application.

I gave myself a challenge: to test a legacy "controller" in isolation, yet with minimal impact on the original code.

She starts with the example code she'll be testing and then works through the steps to effectively test it:

• isolating it from the other functionality in the application
• mocking a statically called method
• requiring necessary files
• executing the controller under test

The post ends with the test class she created showing how to evaluate the result of a call with one invoice in the billing system. She makes one comment at the end to answer the question "why not just refactor" but points out that, especially in larger legacy applications, that's just not always an option.

In a new post to his site Martin Hujer shows you that, with the help of the "script" ability in Composer, you may not need a build tool like Phing. The scripts functionality allows you to execute custom scripts as a part of the Composer workflow, enhancing the management functionality it already provides.

Phing is a great tool (I'm using it as well), but in this article, I want to show you that some projects may not need it. Composer contains a powerful feature called "Scripts", which can be used to create a simple build script.

In his example, he shows how to integrate a run of the PHP_CodeSniffer quality assurance tool as a part of your Composer configuration. This makes it possible to run a command like composer run-script phpcs and automatically run the checks. He then builds on this simple example and creates a more complex build script that still runs PHP_CodeSniffer but also executes PHPUnit tests. He post also shows how to run Composer in a command and how to document each command. There are also a few handy tips included around running Composer on Windows, listing the current scripts and executing custom callbacks to code.

On the Facile.it Engineering blog there's a recent post sharing some tips on how to gradually upgrade your PHPUnit tests to work with version 6 of the popular PHP unit testing tool.

In the latest months I wrote multiple times, in different projects, code migrating PHPUnit toward major version 6. This upgrade is harder than the previous one, since in this version it was introduced a big breaking change: all classes got (finally!) namespaced.

This means that any usage of those classes in your project needs to be updated. [...] In this article I will explain which steps I applied during those migrations, highlighting the most frequent hiccups.

He then start with "the easy one" to take care of the refactor: updating tests to replace the "PHPUnit_*" classes with the namespaced versions. With those out of the way, he talks about "the bumpy one" to handle: modifying test listeners to work with the new PHPUnit structure. Once these are taken care of you can then make the move up to PHPUnit 6 and PHP 7 (if you're not there already) full time.