Behavioural Driven Development (BDD) is exciting to me. That’s becasue the Agile User-Story and Acceptance Criteria, actually become merged with the code-base itself. Bringing them to life, IMHO.
One framework that assists with BDD is easyb, which also has Groovy at it’s heart. Of course, I was keen to see how it could work for me. So here’s my ‘hello world’ type example:
First, I downloaded the latest version of easyb, and pop it in my home folder (or C:\). Then I knock up a simple easyb example story:
package info.savaged.testing.bdd.easyb
description 'This story is about adding'
narrative 'narrative', {
as a 'person doing maths'
i want 'to add two and two'
so that 'I can find the result'
}
scenario 'add two and two', {
given 'two is added to two', {
total = 2 + 2
}
then 'the result should be four', {
total.shouldBe 4
}
}
And another example, this time with some Selenium thrown in:
package info.savaged.testing.bdd.easyb
import com.thoughtworks.selenium.*
description 'This story is about googling'
narrative 'this string is required for now', {
as a 'person who uses google'
i want 'to search for a set of internet links for a phrase'
so that 'I can find information online'
}
before 'start selenium', {
given 'selenium is up and running', {
selenium = new DefaultSelenium(
'localhost',
4444,
'*iexplore',
'http://www.google.co.uk')
selenium.start()
}
}
scenario 'a search phrase has been entered', {
when 'filling out the search with a phrase', {
selenium.open '/'
selenium.type 'q', 'savaged.info'
}
and 'the submit button has been clicked', {
selenium.click 'btnG'
}
then 'the results should have a list of links for that phrase', {
selenium.waitForPageToLoad '5000'
selenium.isTextPresent 'Results * for savaged.info'
}
}
after 'stop selenium', {
then 'selenium should be shutdown', {
selenium.stop()
}
}
Finally, to make use of these behaviour files, an Ant script:
<project name="bdd" default="run" basedir=".">
<taskdef name="easyb" classname="org.easyb.ant.BehaviorRunnerTask">
<classpath>
<pathelement location="easyb-0.9.5.jar"/>
<pathelement location="groovy-1.6.0.jar"/>
</classpath>
</taskdef>
<target name="init">
</target>
<target name="run" depends="init">
<easyb failureProperty="easyb.failed">
<classpath>
<pathelement location="easyb-0.9.5.jar"/>
<pathelement location="commons-cli-1.1.jar"/>
<pathelement location="groovy-1.6.0.jar"/>
<pathelement location="selenium-java-client-driver.jar"/>
</classpath>
<report location="Stories.txt" format="txtstory" />
<behaviors dir=".">
<include name="*Story.groovy" />
</behaviors>
</easyb>
</target>
</project>
Of course, the Ant script expects the easyb libraries and the Selenium java client jar files to be present. And you would need to have started the Selenium server remote control server running. Assuming that’s all in place running:
$ ant
Should produce some affirmative test output along with a file containing the user stories in plain text.
That’s just a silly example, but the possibilities are significant. If the business analysts or other product user in the Agile development team could work in the easyb Groovy format, the tightness of the team could be really enhanced.
IMHO, I think BDD is best compared to functional testing. I believe the User-Story and it’s test scenario(s) fits against the UI testing.
For example simple CRUD at another level of test (unit or integration), would require a fair amount of mocking. One might need to mock the http request and response, in a web-app, for example. Whereas, coming in from the GUI, with a tool set like Selenium or Canoo Webtest, makes for clean BDD code. Especially if one were to use the before and after easyb features. After all, your manager or business sponsor should be able to see what the test is doing, and lots of ’set-up’ code would, no doubt obfuscate that.
