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.

On the SitePoint PHP blog they've continued their series looking at upgrading Sylius, an e-commerce application based on Symfony, with the help of test-driven development methods to ensure nothing breaks along the way. These next two articles cover the use of PhpSpec and using Behat for the different types of testing.

Last time, we developed some new features on top of Sylius’ core to indicate which products and their variants are low on stock and need replenishing. Now, we move on to seeing our changes in the UI, which means we will need to do a bit of StoryBDD testing.

In [the third] part, [we] extend some core classes to indicate color-coded inventory status. First, we’ll deal with the back end part. In a followup post, we’ll use Behat and test the visual changes. Please follow the instructions in the previous post to get a working instance up and running.

In each of the tutorials they walk you through the changes you'll need to make on the Sylius side to test both the Inventory and Product functionality that already come with the package. Examples of each kind of test are included as well as the output from the example test runs.

Robert Basic has a new post to his site with some advice for the Behat users out there testing their Symfony applications. He shows how to easily load up fixture data with the help of Doctrine.

Performing end to end testing of any application requires from us to have a set of reliable test data in the database.

If we write a Symfony application and use Behat to do the end to end testing, the we can use the Doctrine fixtures bundle to create the required fixture loaders and load them in our Behat scenarios when required.

He walks you through the installation of the Doctrine fixtures bundle (via Composer, naturally) and how to enable it via the Symfony kernel configuration. He then includes an example of the fixture loader class from the FOSUserBundle and how it works. Next up is the installation of the Behat Symfony 2 extension and a bit of extra code to make a new feature context for Behat containing a "loadDataFixtures" method to do the heavy lifting.

On the Delicious Brains blog there's a post sharing some of their knowledge about building tests for WP-CLI packages, a set of command line tools for administering a WordPress installation. Their testing makes use of the Behat testing tool (already in use on WP-CLI's own tests).

My last article was part of a short series on automating local WordPress site setup. In that series, we created a WP-CLI package that helps with installing and uninstalling WordPress development environments, and we even got it submitted to the WP-CLI Package Index.

[...] In this post we’re going to take a bit of a break from automating WordPress installs and start writing some functional tests to make sure that everything works as expected. While I’ll be writing the tests for the wp installer command, the same concepts should apply for any WP-CLI package.

They start by clarifying the difference between functional and unit tests and how to get your environment all set up and ready to use for testing. They help you get the wp_scaffold_package installed and how to confirm that everything is working as expected. From there it's all about the tests: ensuring that a package is active, creating a custom step to use in testing and an example of what the output should look like.

The PHP Rountable podcast has posted its latest episode featuring a discussion about Behat and acceptance testing in your PHP applications. This time host Sammy Powers is joined by Jessica Mauerhan and Konstantin Kudryashov.

We chat about the open-source Behavior-Driven Development framework called Behat. We get a brief overview of how Behat can help us write more reliable code and also explore some best-practices when writing automated tests.

You can catch this episode in a few different ways - either using the in-page audio or video player or you can watch the live recording (Google Hangout) directly over on YouTube. If you enjoy the show be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released and when the next shows will be recorded.

The QaFoo blog has a post to their blog introducing page objects and how they're useful in functional testing to help provide a "decoupling" from the actual frontend.

A while ago we wrote about writing acceptance tests (end-to-end tests) with Mink and PHPUnit. While this is a great set of tools for various applications such tests tend be susceptible to changes in the frontend. And the way they break is often hard to debug, too. Today I will introduce you to Page Objects which can solve some of these problems.

The basic idea behind a Page Object is that you get an object oriented representation of your website. The Page Objects maps the HTML (or JSON) to an object oriented structure you can interact with and assert on. This is more initial work then than writing tests with PHPUnit and Mink directly, but it can be worth the effort.

They use the Mnk testing tool to simulate a browser and some previously shared functionality to lay the foundation. From there they write up a first test using a "Login" page object and processing the username/password handling of the page. They show how to implement a custom page object with a bit of additional logic and put it to use in processing the request. They also include an update when, for example, a site is switched from Twig templates to a React.js component and how the Page object would need to be refactored for the update.

On the php[architect] site there's a new tutorial posted from Oscar Merida about testing Drupal sites with Behat, a popular PHP-based "Behavior Driven Development" testing tool to help ensure your application is performing correctly from the outside.

If automated testing is not already part of your development workflow, then it’s time to get started. Testing helps reduce uncertainty by ensuring that new features you add to your application do not break older features. Having confidence that your not breaking existing functionality reduces time spent hunting bugs or getting reports from clients by catching them earlier.

Unfortunately, testing still does not get the time and attention it needs when you’re under pressure to make a deadline or release a feature your clients have been asking for. [...] After reading all the theory, I only recently took the plunge myself. In this post, I’ll show you how to use Behat to test that your Drupal site is working properly.

He starts by listing some of the requirements you'll need to get started (packages installed via Composer) including the installation of a Drupal specific plugin to make testing these sites easier. From there he shows how to configure the Behat tool and write a simple feature to test the visiting of a certain page and looking for matching results. He also includes tips about testing with user authentication, using custom contexts and Selenium integration.

Joeri Timmermans has posted a tutorial to his site showing how you can test drag-and-drop functionality with a combination of the Behat BDD testing tool and the Guzzle HTTP library.

As you could see in previous posts I'm working on a large application for Intracto where they want a lot of fancy visuals and this turned into a mess when it came to write behat tests. This post will help you test position moving with drag and drop.

In his case he was working with a chapter layout that allows for the rearranging of chapters to update their order. The process is then broken up into a few different steps:

• Creating a new context feature for Behat (based on this example)
• Making a custom action that makes it easier to move the chapter entries around by just providing positions
• Calling the move in the Behat test itself

The tricky part here is that the actual test is made for the behavior but the behavior itself is making an API call to rearrange the pages. The test is making this same call and evaluating the result. It's not actually interacting with the page as you might be able to do with something like PhantomJs however.

In this post to his site Antonios Pavlakis "has a go" at creating an extension for the Behat (v3) testing tool. Behat is a testing tool written in PHP that helps with behavior-driven testing as opposed to unit testing with a tool like PHPUnit.

Ever since I got accepted to do a tutorial on Test legacy apps with Behat at the PHPNW15 conference, I’ve been meaning to look into creating custom extensions for Behat. I didn’t have enough time to research into this while preparing for the tutorial, so left it in my todo list in Trello.

During the PHPNW15 long weekend (Friday - Monday), at some point over lunch I was at the table where Matt Brunt (@themattbrunt) and Ciaran McNulty (@ciaranmcnulty) were having a conversation about this and Ciaran said (paraphrasing) “In order to be able to write an extension, you really need to understand how Behat works.”

So a few months later, sleeves up and I went into my vendor/bin/behat and started looking (and poking) around.

After looking in to two current extensions he started to get a feel for what was needed and the pieces that made up an extension. He then gets into detail on each of these pieces and shares some code/configuration he used to create the extension.

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.