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.

Barry van Veen has a quick post on his site showing the Composer users out there how they can use a package from a local directory without having to go through the hassle of pushing it and adding it to Packagist.

Suppose you run a website and want to split part of it into a package with its own repository. You start a new repository and check it out on your development machine. But now you want to see how the website and your new package integrate. How to go about this?

This article explains how you can require a package from a local path into your project with Composer. This way you can run a local copy of a repository and test any changes you make. Because the local repo will be symlinked changes are shared in real-time, there is no need for intermediate committing and updating.

He shows how to update your composer.json configuration's repositories section to add an entry with a "type" value of "path". This then points to the location on the filesystem where the package resides. Then it's just a matter of requiring the dev-develop branch and the code will be treated just like any other package. He also includes a section showing how to handle things when symlinking fails, a problem that usually happens on Windows for VM users. Usually it's related to a permissions error for whatever user is running the VM.

On the Delicious Brains blog there'a a post that compares four different products for creating local PHP development environments: XAMPP, MAMP, DesktopServer and Local. Both package provide similar functionality but with slight differences.

An easy-to-use local testing server is one of the most important tools in a WordPress developer’s utility belt. Developing in a local environment lets you make changes to dev sites quickly and easily without having to transfer files anywhere and greatly reduces the risk of making breaking changes on a live server.

While many computers are capable of hosting a WordPress site without needing to install any extra packages, there are a few advantages that a dedicated local development environment can offer.

[...] There are quite a few different applications and tools that fit this bill, but for now we’ll be comparing the 4 GUI-based tools that seem to me to be the largest players in this space: XAMPP, MAMP (Pro), DesktopServer, and Local By Flywheel.

The post then walks through each piece of software, covering the installation and getting it up and running with a WordPress application. There's also a mini-review for each with good/bad comments and an overall rating.The post ends with some comments about the author's own preferences, which they use now and which they'd choose in the future.

Adam Culp has posted a new tutorial to his site showing you how to set up local debugging inside PhpStorm combining it with the Zend Debugger tool.

Setting up debugging in an IDE with a local development environment has gotten so easy it can be done in a few automated steps. In this post I will demonstrate how to get step debugging functioning with

On the /r/php subreddit from Reddit.com there's a post from Spvrtan asking the community what technologies they're using for local development in their day to day development work.

It's honestly been over 5 years since I last touched PHP on the back-end. At that time, other than "doing it live", XAMPP was the top dog for local environments. Is there a new player in the space or should I go with the same? I've been working primarily as a front-end engineer for the past few years during my full-time employment roles and touched the back-end on projects I've worked on but they've all been Java-based.

They also ask what other developers are using for their deployment tools and pipelines. Answers to the post so far include some of the usual tools and methods including:

• Docker
• puphpet (for use with Vagrant)
• Homestead from Laravel

Other comments also mention the manual creation of virtual machines and even support for local installations rather than virtual ones. What's your development environment like? Head over to the topic and share your own setup too.

The Master Zend Framework site has posted a tutorial helping you create a Docker-based development environment complete with PHP, MySQL and Apache working happily together.

Why in this modern day and age is setting up a development environment still such a complicated process? [...] Why is it still so hard to get one setup that works, that does what you need, and that matches the deployment environment’s of testing, staging, production and so on?

[...] By now our development environments have grown quite sophisticated. But the overhead of both building and maintaining them has increased significantly also. Wouldn’t it be easy if we could set them up, but with only a small investment of time and effort? I think you know where I might be heading with this. You can. Yes, that’s right, you can. Ever heard of Docker?

He then starts in on introducing Docker (for those not already familiar) and how it differs from a VirtualBox/Vagrant setup that's already become quite popular. He talks about "containers" and the role they play as well as an overview of the environment he's going to show you how to create. He then helps you get Docker installed, explains how the containers will work together and provides the Docker YAML configuration for each of them. The docker-compose command is then used to bring the environment up, downloading the containers as needed. The final result of his setup is a set of containers running together to serve up a Zend Framework Skeleton Application.

On the SitePoint PHP blog editor Bruno Skvorc has posted a tutorial showing you how to set up the Packagist alternative, Satis, in a local network configuration instead of requiring users to still access the external web.

While preparing my technical materials for WebSummerCamp, I realized my workshop would rely on a fairly stable internet connection, as we’d have a lot of ground to cover and a lot of packages to install. Rather than rely on the gods of live demos, or pre-installing everything and ruining the experience, I picked another route.

In this post, I’ll show you how to set up a local Satis instance and have it host the packages over the network it’s currently on, so that everyone who’s also connected to it can put the address into composer.json as a custom repository source, and retrieve all packages from your machine locally – no internet connection required!

He then shows you how to set up the system on a Homestead Improved VM locally, cloning Satis inside of it. He includes an example of the configuration of his required packages and how to build the local repository using this setup. Then, using the built-in PHP web server, he shows the result of the setup and how to access it from other machines. Finally, a few updates are required to the user's composer.json to use the local versions instead of the normal remote connection for the package downloads.

The SitePoint PHP blog has a post about a feature Composer provides to help make tools and libraries easier to use - the ability to install things globally. In this post editor Bruno Skvorc wonders if this feature should be "considered harmful" and a bad practice.

We’ve discussed Composer best practices before, and I’ve always advocated using composer global require when installing packages that can be used across several projects – particularly command line tools. Then, the other day, I ran into this discussion. The short of it is – the majority of people now seem to feel like global require is bad practice, unless the globally installed package has zero dependencies.

The article he references offers an alternative option however: install locally to the project and just update your paths to allow for it to be easily found. This can be difficult and hard to maintain so Bruno offers a counter-suggestion, the "[consolidation/cgr]"(https://github.com/consolidation-org/cgr) tool. This tool handles the "global" install in a way that still isolates it and then automatically updates your .bash_aliases with the command and path to make it easier to use.

On the SitePoint PHP blog there's a tutorial posted helping you get started editing and updating the PHP.net documentation, one of the most widely used parts of the PHP ecosystem.

In this two-part article series, we’ll be covering how to contribute to the PHP project. This will hopefully clarify what steps need to be taken for those looking to become more involved with PHP.

This first part will be covering how to contribute to PHP’s documentation, including how to request a php.net Account and what to do once an account has been granted.

He starts with a bit about why you should contribute back to the PHP project and how the documentation is a great place to start. He then gets into the structure of the documentation, the DocBook structure it uses and points to the online editor for the first time contributors. He includes a video showing how to use the system to resolve this bug showing an incorrect MongoDB Client example. For those that would rather do it locally, he shows how to setup and configure the source and required tools. He then shows the flow of updating the documentation, building the result and verifying the update looks correct.

Finally he talks about requesting a php.net account to push the changes back upstream and provides some general tips on things like style guidelines, page ordering and correctly versioning files.