Behaviour Driven Development with RSpec

Monday, April 24th, 2006

Back in February, I told you about Behaviour Driven Development using RSpec. Things have moved in very interesting directions since then.

First, and this is probably the most important, BDD is getting quite some attention, most notably at Canada on Rails. You should check out the Ruby on Rails podcast episode from the 17th of April, where Dave Astels makes an appearance alongside Tim Bray.

On the usage front, RSpec’s DSL has seen some tremendous progress. It reads like plain English. I have not decided yet whether I find it too wordy or simply astonishing! What do you think of this example.

Finally, RSpec now has a good-looking content-packed website complete with documentation, tutorial, examples and all.

There is simply no barrier to its adoption, it just needs traction within the development community. This is where you and me come into the picture. Let’s make RSpec a success, let’s all give it a go: gem install rspec.

You will be amazed at how much RSpec will impact the quality of your code because it changes your perspective on unit testing.

Comments are welcomed and encouraged! That’s all folks, see you next time!

Advertisements

3 Responses to “Behaviour Driven Development with RSpec”

  1. Ed Gibbs Says:

    +1

    I went to Dave’s talk/tutorial on BDD at SD West 2006 and I was impressed. The newest release is even nicer as you say, and I’m looking into using it on a hobby rails project to get a better feel.


  2. Ed,
    I have not had the chance to meet Dave. I suppose this is one of the drawbacks of living in Ireland. I heard him for the first time on the Agile Toolkit Podcast epsiode from the 8th of August 2005. I really liked his philosophy.

  3. Pradeep Jindal Says:

    One more very important aspect of BDD come into the picture when implementing complex systems because its very hard to figure out when to stop working on a module or sub-module. If you are defining required behavior in advance that makes it damn easy to figure out when to stop developing a particular module or sub-module. In other words, I will stop working on a module when all off the behavior cases for that module are fulfilled.


Comments are closed.

%d bloggers like this: