The Disco Blog

The hip team over at easyb.org has been diligently working towards a 1.0 release and recently added the notion of fixtures for stories; that is, the DSL has been updated to include:

• before_each
• after_each

These constructs operate much the same as JUnit’s original fixtures in that code in the before_each closure is executed before each scenario and after_each, after.

As an example of how fixtures can be copasetic, over on testearly.com, easyb was utilized in combination with Selenium to create a more human readable functional story.

The first scenario attempted to capture a sunny day:

• given a user is on the race report page
• when someone enters a first name and last name in the race report form for someone who has signed up for a race
• then they should receive a list of all races that person has singed up for

Yet in realizing this story (as Selenium was utilized) additional aspects related to using Selenium were mixed into the prose. For instance, for every scenario, the following given was needed to fire up a Selenium instance:

given "selenium is up and running", {
 selenium = new DefaultSelenium("localhost",
  4444, "*firefox", "http://acme.racing.net/greport")
 selenium.start()
}

What’s more, because it’s Selenium’s bag, the following then was also required to clean things up:

then "selenium should be shutdown", {
 selenium.stop()
}

These are obviously candidates for pushing into a fixture type construct, right? Consequently, if you need copasetic logic that is repeated for a scenario, you can place it into either a before_each or a after_each construct like so:

before_each "initialize an instance of selenium", {
 given "selenium is up and running", {
   selenium = new DefaultSelenium("localhost", 4444,
      "*firefox", "http://acme.racing.net/greport")
   selenium.start()
 }

 and "given a person is at the race report page", {
   selenium.open("http://acme.racing.net/greport/personracereport.html")
 }
}

Selenium requires some clean up; accordingly, the following construct will be executed post a scenario:

after_each "shut down selenium", {
 then "selenium should be shutdown", {
  selenium.stop()
 }
}

Given this fixture logic, the corresponding scenarios become more concise as their intent is more clearly expressed (without too much selenium mixed in):

scenario "an invalid person should return an error message", {

 given "a form with a first and last name entered and sumbitted", {
  selenium.type("fname", "Merlin")
  selenium.type("lname", "Paine")
  selenium.click("submit")
 }

 then "the report should have a list of races for that person", {
  selenium.waitForPageToLoad("5000")
  selenium.getText("//b").shouldBeEqualTo "no races found for this person"
 }
}

Remember, these fixture constructs are executed for each scenario in a story– at this point, one time fixture logic can be easily added to a story by placing it outside the construct of a scenario. If you haven’t taken easyb for a test drive yet, go for it, man!!