RSpec 1.1 - A Step Up for BDD advocates

Posted by Rick DeNatale on Dec 17, 2007

Sections

Process & Practices,

Development

Topics

Ruby on Rails ,

Ruby ,

Delivering Quality ,

Dynamic Languages ,

Quality ,

Agile Techniques ,

Languages ,

TDD ,

Software Craftsmanship ,

Programming ,

RSpec ,

Agile ,

Rails ,

BDD ,

Testing ,

RBehave

A number of important releases have come out in the Ruby community recently. On December 7, we saw the release of Rails 2.0. Now, David Chelimsky has announced the release of RSpec 1.1.

This new release works nicely with Rails 2.0. The RSpec trunk has been tracking EdgeRails (the development version of Rails, i.e. the one that hasn't been released yet), and developers who are on both EdgeRails and the RSpec trunk have been helping the RSpec team work out the differences. This is one motivation for the release, but there are some other attractions.

One major new addition to the RSpec arsenal is a story runner. Stories come from Dan North's rbehave tool which has been merged into RSpec. Stories are executable statements of application requirements. For Rails users, RSpec 1.1.0 also includes RailsStory. This fills the role of "traditional" Rails integration testing, using Test:Unit, as well as having other uses such as acceptance tests.

One of the disincentives of using RSpec for existing Rails projects which already use Test::Unit is how to make the transition. RSpec now makes this easy. The RSpec runner for Rails has actually been built on top of Test::Unit for over a year. RSpec 1.1.0 introduces a Spec module which can be included in Test::Unit TestCases along with Test::Unit. Once you've done that, you can gradually change from Test::Unit to Rspec syntax. TestCases can be changed gradually to example groups; tests to examples; and assertions to expectations. This allows you to metamorphose your existing TestCases, keeping them working as you go.

Another major new feature is the ability to nest example groups. This makes for more natural sub-specifications, which are variations of more general specifications. in many cases than using the existing shared specification feature of RSpec.
All in all, this is big news for both current and prospective RSpec users.

Are you using RSpec? If not, why not?