RubyConf Day 3: Behaviour-Driven Development with RSpec
Posted by Nick Sieger Sun, 04 Nov 2007 16:26:00 GMT
David Chelimsky and Dave Astels: RSpec
describe TestDriverDevelopment do it "is an incremental process" it "drives the implementation" it "results in an exhaustive test suite" # but also... it "should focus on design" it "should focus on documentation" it "should focus on behaviour" end class BehaviourDrivenDevelopment < TestDrivenDevelopment include FocusOnDesign include FocusOnDocumentation include FocusOnBehavior end
When doing test-driven development:
- Write your intent first. The smallest test you can that fails.
- Next, write the implementation. The simplest thing that could possibly work.
- Even though you may be tempted to think about additional edge cases, multiple requirements, etc., you should try to be disciplined and focus only on the immediate tests. Only after you’ve made one test fail, then pass, can you continue on to other tests.
Initially BDD was just a discussion among Aslak Hellesoy and Dan North in the ThoughtWorks London office. Dave Astels joined the conversation with a blog post stating that he thought these ideas could be easily implemented in Smalltalk or Ruby. Steven Baker jumped in with an initial implementation, and released RSpec 0.1. Later in 2006, maintenance was handed over to David Chelimsky. RSpec has evolved through a dog-fooding phase up to the present 1.0 product.
BDD is no longer just about “should instead of assert”, it’s evolving into a process. Emphasizing central concepts from extreme programming and domain-driven design, it’s moving toward focusing on customer stories and acceptance testing. It’s outside-in, starting at high levels of detail, rather than low-level like RSpec or Test::Unit.
Story Runner is a new feature intended for RSpec 1.1. Each story is supposed to capture a customer requirement in the following general template:
As a (role) ... I want to (some function) ... so that (some business value).
It uses a “Scenario ... Given ... When ... Then ...” format to express the high level stories. Scenarios are a series of given items, steps, and behaviour validations. Once the basic steps are established, they can be re-used. David even demonstrated a preview of an in-browser story runner that would allow the customer to play with the implementation and create new scenarios.
Pending is a nice way to mark specs as “in-progress”. You can either omit a block for your spec, or use
pending inside the block to leave a placeholder to come back to.
describe Pending do it "doesn't need a block to be pending" it "could also be specified inside the block" do pending("TODO") this.should_not be_a_failure end it "could also use a block with pending, and you will be notified when it starts to succeed" do pending("TODO") do this.should_not be_a_failure end end end
Behaviour-Driven Development in Ruby with RSpec is a new book David and Aslak are working on, due out early next year.
Update: David has posted his slides.