This is guest post by Ragazzo. He uses Behat as well as Codeception for making his project better. He was often asked to do a comparison between Codeception, Behat, and PhpUnit. In this post he explains the commons and different parts of this products.

The author talks some about the difference between functional/acceptance tests and how they fit in with behavior driven development. He includes some examples of Behat test formats (Gherkin) and how it can be used for both the functional and acceptance side of things. He also talks some about why he prefers Codeception over Behat(+Mink) for his testing. A sample Codeception test is included, showing a login form check.

Automated testing is big news these days. There's hardly a PHP conference happening without a talk on testing automation or derivative methodologies. TDD (Test-Driven Development) and BDD (Behaviour Driven Development) are all around us. So why should you care about all this? [...] The more complex an application becomes, the harder it is to be sure that each new feature or bug fix won't break the system, and that decreases your overall confidence in your work as developer. That's exactly the reason why you need automated testing - to be confident that you're not breaking important parts of an application.

For his examples he uses a simple Silex-based application (found here on github) that just shows a main page and an "add article" page that returns a preview when submitted. He shows how to get Behat/Mink installed and how to bootstrap PHPUnit to allow you to execute your tests. Also included is a sample test that clicks the "Add Article" link, runs a few checks and fills in some data. The form is submitted and the "preview" page is checked for valid results.

I've already written two blog posts here about Behat: Behavior Driven Development and Code Coverage with Behat. If that made you curious or you wanted to learn about Behat anyway, I can highly recommend to join the free webinar on Behavior Driven Development with Behat I'll be giving on May 8th 2013 on behalf of Qafoo in cooperation with Zend.

As mentioned, the webinar is free to attend, but you'll need to sign up to be able to attend.

I had the occasion to try out and adopt Behat for a particular need in our projects at Onebip. Here is my recount of the experience from a PHPUnit contributor and invested person.

He starts off with a list of situations where he doesn't think that Behat is a good fit for testing including testing of a single object and acceptance tests where comparing the response from more than one test is needed. He suggests that it's more useful for verifying high level business rules than anything. He talks some about the shift they made to using Behat and some of the benefits they found in its use. He finishes up the post by looking at the technical side and includes a warning about letting the size of the FeatureContext file get too large.

There is generally no point in having code coverage for Behat test cases because of their nature: The purpose of an acceptance test is to assert a certain behavior of an application, not to technically test a piece of code. Therefore, there is no point in checking for uncovered code pieces in order to write a Behat test for it. That said, there is still a scenario where you want to peek at code coverage of Behat tests: When creating them as wide-coverage tests before starting to refactor legacy code. Behat in combination with Mink provides you with a great tool for such tests.

They help you get the tools installed and show the code you'll need to add to the application itself to collect the coverage data as the tests execute. It keys off of a file existing/not existing to know if it should execute the coverage or not. The phpcov tool can then be used to generate the HTML output of the coverage information for easy viewing.

While unit, integration and system tests - especially combined with the methodology of Test Driven Development (TDD) - are great ways to push the technical correctness of an application forward, they miss out one important aspect: the customer. None of these methods verify that developers actually implement what the customer desires. Behavior Driven Development (BDD) can help to bridge this gap.

The introduce some of the basic concepts behind behavior driven development and include an example of a Gherkin-formatted test example checking a page to ensure if has the correct content. They briefly define the structure of the test then take it into a Behat context and show how it would be implemented.

Of course, the examples shown above are only very rudimentary, missing e.g. variables and other advanced features. However, they should have explained what BDD is all about: Communication

Sometimes I need to stop/start remote Windows services with PHP. It's quite easy to do it with net commnand. This command is a tool for administration of Samba and remote CIFS servers. [...] Today we are going to create a PHP wrapper for [net rpc service].

He uses Behat to create a feature (test) file, the code behind the features and a service class that handles the actual work of interacting with the service (with methods to do things like stop, start and list running services). Examples of its use are also included.

BrowserMob Proxy is a utility which is used for capuring HTTP traffic and performance data from the browser. BrowserMob-Proxy adds in essential missing capabilities such as checking HTTP status codes and injecting headers for HTTP Basic Auth. Web Perfomance data can be manually captured by other tools like Firebug or Developers Tools. Using BrowserMob Proxy we can capture perfonace data in HAR format while running automated tests.

He includes the commands you'll need to set up the PHP interface for BrowserMob (PHPBrowserMob) the proxy itself and a sample test and context file that runs some checks against Facebook.

Behat scenarios are one of the best ways to describe system. UML Use Cases or tons of pages in SRS documents are fine, but hard to understand from the begining, and even harder to maintain in the future. Behat eases this process and also gives opportunity to automate requirements verification. To write Behat scenarios you need a text editor. I've picked my favourite - Vim, which highlights *.feature files syntax. But business people mostly don't use Vim, so I need to figure a way, to expose scenarios in easy and pleasant way.

His solution involves setting up some printing options in vim to export the tests as a Postscript file, setting the "colorscheme" to the default setting so the colors will be retained. The result is exported (via the "hardcopy" command) and can be converted into a PDF (with a result like this).

Behat has becoming so popular in recent days. Behat has drastic changes in recent days in order to add some cool features into it. [...] In this tutorial, we will see how to upgrade Behat vesion with use of composer . Most of us have been installed Behat with 'pear' packages. behat version installed with pear has no longer supported.

He includes the commands to remove the current PEAR install (if it's there) and what you'll need to add to your "composer.json" file to pull in the main Behat package as well as the Geherkin parser and Mink extension. There's also a command you can use to be sure everything's working correctly.