In this new post to his blog Shashikant Jagtap talks about a new extension for Behat (the BDD testing tool) that makes working with Mink even easier - MinkExtension.

'MinkExtension' has been just released which has additional services for Behat. This extension has 'Mink' instance for your 'FeatureContext' and 'SubContext'. UI testers would be happy now, as they don't need to create Mink instance every time in order to use Mink API's.

He points you to an example application you can use to follow along. He includes the commands needed to install the dependencies via Composer and get this extension working (note: it requires PHP 5.4 for some of the traits stuff. If you don't want to use that, comment out the "TraitedFeatureContext.php" file). Also included are the commands to execute the tests with a Selenium server and a list of a few handy new things this extension enables.

On his "Let's BDD" blog Shashikant Jagtap looks at the integration of Saucelabs and Behat for even more functionality when creating BDD tests.

On the occasion of Selenium Conference, I met with Noah Sussman talking about "Selenium In the Enterprise: What Went Right, What Went Wrong (So Far)" and one of his slides indicated that, team using Behat and Mink for the functional testing at Etsy. Noah then introduced me to Laura Beth who setup Behat/Mink and SauceLabs integration. Behat-Sauce configuration by Laura Beth is very easy to use. Now, we will see this in action.

Shashikant shows how to clone the github repository for the behat-suacelabs tool Etsy uses, use Composer to get all of the needed dependencies and a sample set of tests showing a sample set of Scenarios and their matching features (code). You can watch a video of the result here.

Earlier this month Shashikant Jagtap wrote up a post about a powerful combination in testing your applications - a "rockstar" combo of PHPUnit + Behat/Mink + Page Object to give you a great foundation for BDD (behavior-driven) testing.

Last month, we had discussion about implementing page object pattern in Behat/Mink framework at London Behat Users meetup. Page object pattern is a cool way to make tests maintainable, reusable and readable. Everyone was interested to know more about Page Object Pattern. In this short tutorial, we will implement Mink and PHPUnit combination for functional testing. Mink and PHPUnit combined with Pageness (Page Object) can be used for maintainable and readable tests.

He assumes that you might not have all the tools needed installed, so he walks you through the setup/install of PHPUnit, the PHPUnit-Mink framework and both the Sahi and Selenium drivers. He includes a basic directory structure for the testing and shows how to create some Page Object classes that extend the default TestCase and make calling the remote resource simple. He also includes the steps needed to execute the tests via PHPUnit.

Chris Hartjes has taken some of his first steps to testing a web service with the help of the Behat BDD testing framework. In this new post he shares some of that knowledge and a bit of code to help guide you if you'd like to get started yourself.

I have been trying to push my JavaScript skills lately by first playing around with Node.js to get a feel for event-driven server-side coding and by trying to build something semi-useful using Knockout. [...] After working with PHPUnit's "assert that the result matches expectations" philosophy, switching to using a behavioural approach has changed how I decide to approach actually testing something.

He shows how to define a "scenario" in a more recognizable sort of English. His example is testing a web service to ensure of a few things:

• the response is JSON
• it contains at least one transaction
• the first transaction has an ID, contains two teams and has a description

Included in the post is the resulting Behat test code (generated and modified with his testing details) and an example of the execution of the test.

I think that the BDD approach maps better to a results-oriented methodology when it comes to testing: you are using real-life scenarios to make sure that you are getting back the results you are expecting. In the end. that is still the goal of testing.

In this new post to his blog Chris Hartjes offers up a few of his own thoughts about testing APIs and some of the issues/concerns he's come across in his own testing (via Behat).

I have been asked a few times on Twitter for some advice on how to use testing tools in order to test APIs. It just so happens that I am writing a bunch of tests for an API at work so perhaps this is a very timely blog post. [...] When you are testing an API you main concern is your ability to reproduce the results of a specific API call. If your API is such that repeating a call several times will give you different results, you do have some challenges on your hands.

He talks about functional testing, the "moving parts" they involve, using only known data sources and the creation of integration tests. He also mentions the testing of your local application to ensure it's handling (or transforming) the results of the API calls into something useful.

In the end, it doesn't really matter what tools you are using to test either your own APIs or ones that your application depends on. Be clear in your mind about what it is you are actually trying to accomplish and don't get create tests that provide very little value to your application.

Jakub Zalas has a recent post to his blog with a hint about how to test Symfony container services by mocking them (when testing with Behat) with the help of Mockery (and the PSSMockeryBundle).

Mocking objects in unit tests is pretty straightforward as every object used in a test case is usually created in a scope of one test class. In functional tests it's a bit harder since we either don't have full control over objects being created or it's simply too laborious to mock half the framework. [...] We're getting the service from a container [in the example] and calling a method which should send a lead. The problem is we don't want to actually call an API while executing Behat scenarios.

Rather than hitting up the API for each test, he opts to create mock objects and results with the tools Mockery has to offer. He gives code for a "is API available" method that either returns a valid container or a mocked object, depending on how it was called.

In a recent post to his blog Alessandro Nadalin looks at a different approach to development than the usual code-first, ask questions later style, behavior-driven development, and a tool that can help you follow this method - Behat.

Although this requirement is not mandatory, BDD's power is leveraged by using stories. It basically assumes that instead of focusing on tests, we should start our development process writing down a story that a parser can translate into a test (a customer cares about features, not tests) a programmer can implement in order to verify that our software respects that story.

He talks about installing Behat via PEAR, how it can integrate with Symfony (1.4) and an example of a sample story/test file that checks a few things against a basic page. He also points out an interesting and quite useful feature of Behat - outputting the tests in a HTML-formatted result that makes for easy reading by non-developers.

On the Ibuildings techPortal today there's a new post from Marcello Duarte looking at a different sort of software development methodology - behavior driven development - and using Behat in a sample project.

Because of the emphasis on test, developers tend to focus on class structure as opposed to how the system should behave. Ironically the focus on test moves developers away from TDD as it was intended. Quite often, because of the tendency to try to test everything, our tests end up tightly coupled with our implementation. If we change our code, we break our tests, even if the behaviour remains unchanged.

He talks about the option to use the agiledox method in PHPUnit tests and how it can help with test output readability. He takes it a step further with a look at Gherkin, the language for the Cucumber testing tool in Ruby. The next obvious step in the process comes with Behat, a sort of PHP version of the Cucumber testing tool. He includes a sample project and shows how to update it with sample steps and create a few basic tests to check video rental information.

Leng Sheng Hong has submitted about a project posted recently he's developed to make behavior-driven development in PHP easier - ArBDD.

ArBDD is a simple yet powerful BDD library for PHP to get you started with BDD in PHP. Excellent for those who have no previous experience with BDD.

The project's page includes some basic code definitions of behaviors the code should follow, the creation of a simple mock object and the JSON-based results that come out when the tool is executed. They've also created an AIR-based viewing tool to see the results outside the browser. The code requires PHP 5.3+ because of its use of closures.

For another example of BDD testing in action, look at the Behat framework, based on the Ruby Cucumber syntax.

Konstantin Kudryashov has linked to a new tool that's adds BehatMink browser abstraction library for your Symfony2 project as a part of the Behat project (a BDD testing tool for PHP).

You can now test your Symfony2 applications with PHPUnit and Mink, thanks to brand new MinkBundle.

This new tool provides a clean API, support for Symfony2's test.client browser emulator and support for the Goutte and Sahi browser emulators as well. In the README on it's github page, they've provided some sample code snippets that show how to register the namespaces, add it to your application kernel/add the config, enable the GoutteDriver and SahiDriver and, of course, write a first test.