On the TechBeacon site they've posted an article about choosing the right testing tools for your codebase and why making the right choice matters.

Fast end-to-end tests are the next big thing. The tooling has improved tremendously, and the productivity and insight gains are too good to ignore. Modern tools such as Cypress and >TestCafe are becoming quite impressive and can give you confidence in your product's quality.

As with most facets of software development, there is a balance to be strived for between speed and test confidence. The leverage point depends on the project, and the two most common types of software project these days are web services and enterprise software.

They talk about some of the differences between the testing of web services versus enterprise software as well as some of the practical advantage of fast tests. They also cover the advantages of broad tests and cover some of the current tools for testing including Cypress.io and Laravel Dusk.

In a post to his Medium.com site TJ Miller has a quick post for the PHPUnit users out there showing how to isolate your tests and prevent them from interacting by splitting them into different test suites.

On a recent Full Stack Radio episode Adam Wathan and Taylor Otwell were talking about testing Laravel applications. During the episode, they spoke about isolating interactive integration tests from your normal testing e.g. payment gateways, third-party integrations.

TJ shares an example of a project he's working on where this is useful: avoiding interactions with an HTTP API every time the tests run. He then shows how, with a single PHPUnit configuration, you can split up the tests by name and directory to prevent them all from executing every time. Then the "testsuite" option can be used to isolate the execution from the command-line. An example of the XML configuration is also included in the post.

On the Lakion blog there's a recent post sharing how they used the Blackfire.io profiling service to [speed up their application's tests] (Behat)(http://lakion.com/blog/how-did-we-speed-up-sylius-behat-suite-with-blackfire) and find the "pain points" to fix.

Feedback time is one of the most crucial factors during development and the red - green - refactor cycle. In case of Sylius, the full build used to take two and a half hour, including 55 minutes for only PHP 5.6 jobs. Waiting so long for feedback is not an option for a project of this size and with so many active contributors. As much as I am Xdebug fan, I have never really used it for profiling - the snapshots generation was slowing down the profiled script significantly and resulted in monstrous files, which weren't easy to read.

Half a year after I have first heard of blackfire.io I decided to give it a try. It resulted in a series of pull requests that speeds up Sylius test suites 6 times and reduces memory usage to one tenth.

They go through some of the major bottlenecks that the service helped them locate including:

• an issue with the login process and their role evaluation handling
• problems with time spent doing router initialization
• Doctrine performance issues running it without a class metadata cache

For each item they describe what the service was reporting and how they corrected it in the application. Most of the changes were relatively small, fortunately. They also link to the results from before and after the changes so you can see the difference. As their environment is Symfony-based they end the post with some other helpful Symfony tips to getting the most out of your application and enhancing its performance in a few simple ways.

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.

In a new post to his blog Matthew Weier O'Phinney talks about using the Zend_Test component of the Zend Framework to set up test suites on your application.

Testing and test automation should be easy and the complex approach is overkill for most of our applications. Fortunately, PHPUnit offers some other methods that make doing so relatively simple. The easiest method is to use an XML configuration file.

He includes a basic XML config file for a "My Test Suite" setup defining the application's directory and where to log the end report to. This simple PHPUnit configuration can be used with the "phpunit" command line binary to auto-configure all you'll need for the testing. Matthew also includes the code for a sample TestHelper you can drop right into the app to help set up your environment correctly when testing is needed.

As per this post to the ThinkPHP Blog, the latest version of PHPProjekt (5.2) has been made available.

Mayflower announces that Version 5.2 of its free popular open source groupware suite "PHProjekt" is available immediately and ready for download.

Updates in the new version include a refactored user interface, Dojo integration, porting it over to the IBM DB2 database system, an update to the Helpdesk, and automatic email functionality.

Get full information on the PHPProjekt from www.phpprojekt.com.

As per this post to the ThinkPHP Blog, the latest version of PHPProjekt (5.2) has been made available.

Mayflower announces that Version 5.2 of its free popular open source groupware suite "PHProjekt" is available immediately and ready for download.

Updates in the new version include a refactored user interface, Dojo integration, porting it over to the IBM DB2 database system, an update to the Helpdesk, and automatic email functionality.

Get full information on the PHPProjekt from www.phpprojekt.com.

As part of a project he was working up, Cory Rauch has created some statistics comparing the performance of the latest PHP 5 series release, PHP 5.2, with the previous version, PHP 5.1.

I can't say the results of the benchmarks are surprising, but it does give a good idea of where, speed-wise, they really improved things in this new release. There are some stats, though, that didn't make that much of a jump. Those seem to be ones dealing with objects and their handling, though - so there's not that much of a jump there anyway.

He tested all sorts of operations, including working with binary data, string and array functionality, looping (for, foreach, etc), and operators. For each statistic, he provides what the test is doing and what the results are. Testing was done with the PHPLens benchmark suite.

As part of a project he was working up, Cory Rauch has created some statistics comparing the performance of the latest PHP 5 series release, PHP 5.2, with the previous version, PHP 5.1.

I can't say the results of the benchmarks are surprising, but it does give a good idea of where, speed-wise, they really improved things in this new release. There are some stats, though, that didn't make that much of a jump. Those seem to be ones dealing with objects and their handling, though - so there's not that much of a jump there anyway.

He tested all sorts of operations, including working with binary data, string and array functionality, looping (for, foreach, etc), and operators. For each statistic, he provides what the test is doing and what the results are. Testing was done with the PHPLens benchmark suite.

Sebastian Bergmann asks a simple question in his latest post - "who uses PHPUnit?"

I am putting together a list of projects that use PHPUnit. The purpose of this list is not only to show who uses PHPUnit but also to provide a list of example test suites that are built using PHPUnit.

More specifically, he's looking for projects that use PHPUnit that isn't listed on this page. If you have a project or know of one that's using this popular unit testing suite, post a comment here to let him know.