Joseph Wilk

I recently wrote an article for ‘The European Software Tester’ magazine which looked at ways Cucumber, Acceptance tests in general and practices around Behaviour Driven Development can help avoid the gap between what the customer wants and what they get. I’m happy to say the article has been published and is also available digitally:

European Software Tester – 09 March Issue - Page 28

We want to be able to commit our code frequently to prevent merge headaches.

“the longer you wait, the more your code will diverge from your teammates. If you don’t commit often you rob them of the opportunity to reduce merge hell.” Aslak Hellesøy

When dealing with Cucumber and Features/Scenarios we may find we want to commit part way through a scenario but we won’t because:

1. We don’t want to break the build
2. We don’t want to pollute the build with lots of pending steps.

A common solution to this problem is to create two streams for running the features:

1. In-progress
   • If an in-progress scenario fails then the build carries on.
   • If an in-progress scenario passes then the build fails (This is very similar to how Rspec works with pending)
2. Finished
• If a completed scenario fails it causes the build to fail.

We can implement this model using Cucumber’s new Tag feature. We can tag Scenarios and Features with @in-progress and use this tag to help exclude in-progress Features/Scenarios from the finished build.

@in-progress
Feature:
  In order to avoid merge headaches
  As a developer
  I want to tag my features and scenarios with a in-progress tag

  @in-progress
  Scenario: I'm not finished yet
    Given ...
    When ...
    Then ...

The Rake tasks

Finished features/scenarios task

We prefix tags with ~ to exclude features or scenarios having that tag

  desc "Run finished features"
  Cucumber::Rake::Task.new(:finished) do |t|
    t.cucumber_opts = "--format progress --tags ~in-progress"
  end

In-progress features/scenarios task

  desc "Run in-progress features"
  Cucumber::Rake::Task.new(:in_progress) do |t|
    t.cucumber_opts = "--require formatters/ --format Cucumber::Formatter::InProgress --tags in-progress"
  end

We require a special formatter Cucumber::Formatter::InProgress which is essential for making the task work. This formatter as well as giving helpful output changes the command line exit codes of Cucumber. This is kind of crazy but only within the formatter do we have enough information to decided if we should fail or pass. The formatter only returns a failure exit code if there were any scenarios which passed. So unlike the default exit codes failing steps will not cause a failure exit code.

Full Source Code

Also available at: http://github.com/josephwilk/cucumber_cocktails/tree/master

Read the rest of this entry »

I was speaking in Edinburgh at Scotland on Rails 2009 about Cucumber and Rspec.

You can watch the recorded full talk.

I’ve also posted the slides from the presentation and uploaded the screencasts used in the presentation in both high and low resolutions. They are accessible from links within the presentation.

Here are some of the useful links from the presentation:

• Cuke’s official website – http://cukes.info
• Cucumer’s github wiki – http://wiki.github.com/aslakhellesoy/cucumber
• Rspec’s website – http://rspec.info
• The Rspec book – Pragmatic book store – http://www.pragprog.com/titles/achbd/the-rspec-book
• In-memory browser testing – Webrat – http://wiki.github.com/brynary/webrat
• Browser based testing – Watir – http://wtr.rubyforge.org/
• Browser based testing – Selenium – http://seleniumhq.org/
• Headless Browser testing – Celerity – http://celerity.rubyforge.org/
• Using Celerity from within Ruby – Culerity – http://upstream-berlin.com/2009/01/28/culerity-full-stack-rails-testing-with-cucumber-and-celerity/
• Website for checking regular expressions – Rubular – http://www.rubular.com/

I would like to thank the organisers, everyone who came to listen and speak at the conference. It was a pleasure to be a part of such an enthusiastic group of people in such a beautiful venue.

Cucumber as of version 0.2 has removed the GivenScenario feature. GivenScenario was introduced in the original story runner to allow calling a scenario from another within the same feature.

Scenario: setup
  Given ...

 Scenario: example
   GivenScenario setup
  ...

I initially thought this was a great feature (as mentioned in Rspec stories from the trenches). However when I was using GivenScenario I was thinking as a programmer, which is usually where you start going off the tracks when writing features.

Lets look at an example of GivenScenario
Read the rest of this entry »

I’ve been developing multiple systems using Rspec stories for a little while now. There are a lot of great resources to get you started with a taste of what you can do with stories. Some of the resources I found useful where:

• http://peepcode.com/products/rspec-user-stories
• http://blog.davidchelimsky.net/2008/6/16/slides-from-railsconf
• http://www.benmabey.com/2008/02/04/rspec-plain-text-stories-webrat-chunky-bacon/
• http://dannorth.net/whats-in-a-story
• http://evang.eli.st/blog/2007/10/8/story-runner-top-to-bottom-screencast

However once I had understood the basic idea I struggled to find practical examples and general guidance on writing real stories. So I’ve collected some of the lessons I’ve learnt along the way with story examples taken from real systems and how I’ve improved them as I learnt. Most examples are from web based applications.

Read the rest of this entry »

Rspec-rails is a rails plugin which brings the Rspec Ruby Behaviour Driven Development framework to rails along with some rails specific helpers. One of these hugely useful helper functions is:

mock_model(model_class, options_and_stubs = {})

This creates a mock object with the common methods stubbed out. It also allows you to specify other methods you want to stub.
Read the rest of this entry »

When using Rspec stories you have plain text stories which we call the ’story’ file and the ’story steps’ file that maps the plain text story to programmatic code. Generally you end up with your story files not being DRY. This is not a worry, your stories are the domain specific languages detailing your acceptance/integration tests. Its like saying that your Rails Models are not DRY because they repeat lots of 'has_one'!
Read the rest of this entry »

Funkload is an open source python based unit testing tool. It serves as a good tool for load testing. We can use it to create a unit test which simulates a user browsing through a site. To test load run two simultaneous instances of the unit test and so on scaling up the number of concurrent instances.

Offical Site: http://funkload.nuxeo.org/

I have written a python based Funkload build script which:

• Builds the Funkload configuration for multiple sites
• Uses wget to generate sample of pages for load testing
• Runs load tests
• Builds HTML documentation from test results.

Read the rest of this entry »