In a previous post I showed you how to use HTTP Auth with the Goutte driver in Behat testing. I want to take a step back and show you how I even got to that point with a simple guide to installing the tool and creating your first tests. In a future post, I’ll show the (super simple) integration you can do with Jenkins to execute the tests and plug in the results.
First off, a definition for those not sure what Behat is:
Behat was inspired by Ruby’s Cucumber project and especially its syntax part (Gherkin). It tries to be like Cucumber with input (Feature files) and output (console formatters), but in core, it has been built from the ground on pure php with Symfony2 components.
And, for those not sure what Cucumber is:
Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format.
These are both tools that implement something called behavior-driven development, the practice of approaching testing from a more natural angle, allowing tests to be written in “plain English” (or the language of your choosing with Behat) and executed at a domain level rather than a code level (as unit tests would). Behat makes this super simple and it really only takes a few minutes to get it up and running.
For my examples, I’m going to be working on a Linux-based system (CentOS actually) but the same kinds of ideas apply to other platforms too, just modified slightly for things like pathing. So, let’s get started…first off, the installation. Personally, I recommend the Composer method for installation – it just makes it easier to get everything you need without having to think hardly at all.
Here’s a set of commands (linux command line) to get everything set up for a basic project structure:
mkdir behat-testing-ftw; cd behat-testing-ftw;
curl -s http://getcomposer.org/installer | php
vi composer.json
Inside the composer.json file, enter the stuff from the Behat instructions here (the JSON format), then we can run composer on it:
php composer.phar install
At this point you should see a bunch of things being installed in the “Installing dependencies” section (at the time of this post, that includes things like symfony/finder, symfony/dependency-injection and behat/gherkin). Once this is finished, you should have a directory structure similar to:
Chriss-MacBook-Pro:behat-testing-ftw chris$ ls
bin composer.json composer.lock composer.phar vendor
Behat should be magically installed in the bin/ directory – to test it out, try this:
Chriss-MacBook-Pro:behat-testing-ftw chris$ bin/behat
If all goes well, you should see a big red error talking about “features” not existing. This is good – we’ll fix this now by making the testing base for Behat. Thankfully, it makes this easy too:
Chriss-MacBook-Pro:behat-testing-ftw chris$ bin/behat --init
+d features - place your *.feature files here
+d features/bootstrap - place bootstrap scripts and static files here
+f features/bootstrap/FeatureContext.php - place your feature related code here
Your directory should now look like this:
Chriss-MacBook-Pro:behat-testing-ftw chris$ ls
bin composer.json composer.lock composer.phar features vendor
The new features directory is where your Behat tests will live. If you look in there now, there’s not much – just a bootstrap directory with a FeatureContext.php file in it. This file is where you’ll define any custom rules you might need to use outside of the pre-defined ones Behat (and later Mink) come with. If you re-run Behat again, you should see:
Chriss-MacBook-Pro:behat-testing-ftw chris$ bin/behat
No scenarios
No steps
0m0.001s
So, let’s give Behat something to do now – Behat tests are organized in “feature” files. Let’s make a simple one for illustration and call it “sample.features” and put some content in it:
cd features
vi sample.feature
And put the following inside it:
Feature: Testing Behat install
This is a testing feature to see if everything
is working correctly
Scenario: My first test
When I run "ls"
Then I should see the file "composer.json"
By default, Behat doesn’t come with any contexts pre-defined (you can see this by executing /bin/behat -dl) so we’ll need to make some for our new feature. Thankfully, Behat makes this simple too (sensing a theme here?) – if you run behat again, you should get something similar to:
eature: Testing Behat install
This is a testing feature to see if everything
is working correctly
Scenario: My first test # features/sample.feature:5
When I run "ls"
Then I should see the file "composer.json"
1 scenario (1 undefined)
2 steps (2 undefined)
0m0.051s
You can implement step definitions for undefined steps with these snippets:
/**
* @When /^I run "([^"]*)"$/
*/
public function iRun($argument1)
{
throw new PendingException();
}
/**
* @Then /^I should see the file "([^"]*)"$/
*/
public function iShouldSeeTheFile($argument1)
{
throw new PendingException();
}
Se those last few lines? That tells you exactly what you’ll need to drop into the FeaturesContext.php file to make things work. The key to the matching is in the DocBlock comments – there’s regular expression matches in there that Behat tries to use when it’s executing the tests. So, let’s update our FeaturesContext with some new code:
vi features/bootstrap/FeatureContext.php
And insert into the class the following:
[php]
/**
* @When /^I run "([^"]*)"$/
*/
public function iRun($command)
{
exec($command,$result);
$this->output = $result;
}
/**
* @Then /^I should see the file "([^"]*)"$/
*/
public function iShouldSeeTheFile($fileName)
{
if (!in_array($fileName,$this->output)) {
throw new Exception(‘File named ‘.$fileName.’ not found!’);
}
}
[/php]
This code tells Behat to execute the $command (via exec), return the results to the “output” property and then check to see if the $fileName is in the list. As long as you were in the main “behat-testing-ftw” directory when you executed this, all the tests should come up green:
Feature: Testing Behat install
This is a testing feature to see if everything
is working correctly
Scenario: My first test # features/sample.feature:5
When I run "ls" # FeatureContext::iRun()
Then I should see the file "composer.json" # FeatureContext::iShouldSeeTheFile()
1 scenario (1 passed)
2 steps (2 passed)
0m0.016s
To see how it looks when tests fail, try changing the filename in the sample.feature to something like “composer.json-foo” and you’ll see that step turn red.
So, that’s pretty much it – that’s, in a nutshell how to get Behat testing up and running (via the Composer option). There’s a few minor things that I came across when I was trying to execute the Composer and Behat tools, but those usually stemmed from missing PHP functionality/packages not being installed on the server. Those were solved with a quick “yum install” call for the needed functionality.
I hope to continue this series and talk next about getting Mink up and working to add some really useful features to Behat. I’ve been using it for testing a REST service, so that’s one of the end goals.
blog.phpdev 