[embedGitHubReadme owner=”jaffamonkey” repo=”cucumberjs-protractor-kickstart”]
[embedGitHubReadme owner=”jaffamonkey” repo=”behat-3-kickstart”]
[embedGitHubReadme owner=”jaffamonkey” repo=”protractor-jasmine”]
[embedGitHubReadme owner=”jaffamonkey” repo=”cucumberjs-protractor-basic”]
Behat with Docker
[embedGitHubReadme owner=”jaffamonkey” repo=”docker-behat-1″]
Guerilla test management – it became my accidental niche area. From 2000-2011, I was working in primarily creative, publishing, mobile and media companies in QA/Test Management capacity – usually hands-on (asides pure strategy/management based contracts). Either welcome or not, I was hired for my pragmatism and multi-disciplined QA skills. I have built test environments on the sly (not kidding), experienced sabotage, back-stabbing, blame-game defences. I have managed distributed teams, and have been a lone QA on multiple projects. I often had to learn new things, at speed. What never changes (rarely) is my good-natured optimism, and refusal to allow others negativity to affect me. But, a few years ago, I had grown tired of my management direction and tired of unhealthy chaotic projects I was hired to improve QA within. On a personal level, the work felt vague with no focus, and increasing dissatisfaction.
So what are we really building when we develop in test on a BDD project? A test framework, a test application? Well, both of these, but most importantly it is a debugging application, ideally integrated into CI and/or whatever the code build/deploy process the code goes through. Sometimes the debugging application is part of the application under test, and all for the better.
Feature: As a user,
I want to be able to see accurate count of search terms in search results.
Scenario: Check for search term count on page
Given I am on the homepage
And I fill in "Behat" for "s"
And I press "Search"
Then I should see "Behat"
And count of "24" instances of "Behat" exists on page
Lets take the last step and follow it through to the test code. behat uses regex to parse the natural language line, to map to particular test code, in this case the countTheElements function.
* @Then /^count of "([^"]*)" instances of "(?P[^"]*)" exists on page$/
public function countOfExistsOnPage($count, $area)
# calls the Homepage class which contains the test function code
Test code can get messy quickly, so following page objects approach is sensible both for readability and reusability.
So the actual functional code is stored in another file. This approach means both the Gherkin AND code is more reusable.
class Homepage extends Page
* @param string $count
* @param string $area
* @return Page
* @throws Exception
public function countTheElements($count, $area)
$str = $this->getDriver()->getContent();
$count2 = substr_count($str, $area);
if ($count != $count2)
throw new Exception($count . ' is incorrect, it should be: ' . $count2);
Gherkin is code – it’s a the single most misunderstood part of BDD and associated tools, most of which use (or at least support) the Gherkin specification language. I don’t doubt this is because it is written in natural language, and so people automatically look for the complication rather than just taking it for what it is. A structured approach to specification. Code itself doesn’t have to be unreadable, as there is more than one way to write code, and naming conventions for methods, functions, classes and variables can go a long way to making code more readable. Test engineers, should aspire to the same with test automation.
Behat 3 Kickstart Repo