We’re committed to making the upgrade from rspec-1.x to rspec-2.0 as seamless as possible for most users, but extenders are going to see some differences. This is why we’re going to take our time with alpha, beta, and candidate releases.

Here are some of the improvements you can expect:

Modularity

Following the Rails and Merb models, Rspec-2 will be broken up into component gems and a meta-gem that depends on them. Most users will still gem install rspec, and doing so will install the component gems.

We’ve broken rspec up into 4 repos in the rspec account on github:

• rspec => meta gem that depends on the others
• rspec-core => runner and output formatters
• rspec-expectations => should and matchers
• rspec-mocks => mocks and stubs

With separate component repos, you’ll be able to use rspec as you do today or mix and match components with other frameworks. This will also make it easier for contributors to contribute to the components they are interested in without worrying about other components.

New runner extracted from Micronaut

The rspec-core repository is a complete rewrite of the runner, which has been a big sore spot over the years for contributors and extenders. We extracted the runner from Micronaut, which is an Rspec-compatible framework written by Chad Humphries.

Micronaut has a simple and powerful metadata model, which allows us to easily slice and dice a spec suite in much the same way we do now with Cucumber using tags. It also helps to simplify rspec’s own specs (because you can access it from within an example).

Because we’re able to intercept examples before they are run, we’ll also be able to offer a clean extension API, allowing you to add structures like Merb’s given blocks without monkey patching. Less monkey patching == more maintainable.

Where we are today

While Micronaut runs the same specs that Rspec does, there are some different names for things, and there are some differences in the CLI as well. We’ve started to resolve some of the differences in rspec-core, but we have a way to go.

If you want to try it out and see what works and what doesn’t, you can either install the prerelease gems (2.0.0.a2 as of this writing):

[sudo] gem install rspec --prerelease

You can also grab the dev environment and have a look at the code. See the rspec-dev README for info.

Please do not start reporting issues yet as this will only slow us down.

There is a lot that works, but there is also a lot that doesn’t. Once we get to beta, we’ll be looking for feedback and contributions, but for now we just want to let you know where things are.

Rspec 2 uses Rspec as the root namespace and installs an rspec command instead of a spec command. Until we release 2.0.0 final, this will make it easy for you to keep things separate on your system and in your apps. Once we go final we’ll either alias the old names or release a separate backwards-compatibility wrapper gem that does this for you.

What’s next

We want to focus most of our efforts on rspec-2 at this point, so we don’t plan any new development on the rspec-1.x series. We’ll do bug-fix releases of rspec[-rails]-1.3, but no new features.

I’ll follow up with more information as it becomes clear. Look here for announcements about alpha and beta releases if you’re interested in trying it out early or getting involved.

Late last week and through the weekend, Engine Yard, Relevance and Obtiva sponsored a meeting with Yehuda Katz, Carl Lerche, Chad Humphries, and me. The four of us laid out some groundwork and made some good progress toward what promises to be be a very friendly world for Rspec and Rails users and extenders.

Thanks to David Heinemeier Hansson and the rest of the Rails core team for embracing agnosticism without compromising convention over configuration.

I’ll follow up with details as things shape up, but here is a quick synopsis:

Rails users

Whether or not you use Rspec, you’ll see improvements in some of the built-in assertions, and other testing facilities that ship with Rails.

Rspec-rails users

If you do use Rspec, you’ll see a new rspec-rails plugin/gem that hooks into new features of rails-3 like the new rails generators. You’ll also see support for Merb-style request specs that wrap Rails’ integration tests.

Test framework authors

Rails’ testing APIs will be decoupled from the Test::Unit and Minitest runners. For authors of new testing frameworks, this means that you’ll be able to include a module in your framework’s objects instead of having to subclass TestCase. This will make it much easier to experiment with new ideas in the context of Rails, which clearly exposes those ideas to a wider audience than otherwise.

Chad wrote an Rspec-compatible framework named Micronaut, which runs specs written for Rspec. With Chad on board, we’re replacing Rspec’s runner with Micronaut’s runner for rspec-2.0, which is already in progress and should be released with a new rspec-rails-2.0 plugin/gem in time for the Rails 3.0 release.

Check back here for more details over the coming days, but in the mean time:

Welcome, Chad!

I just started back a little over a week ago and, this week, started the couch to 5k schedule. For those of you who have never run, or haven’t run in years, this schedule is absolutely fantastic.

It starts off with with alternating intervals of jogging for a minute and walking for 1.5 minutes for a total of 20 minutes. I immediately found that I was pushing much harder than normal for me during the 1 minute jogs, and after the 20 minutes I felt great! One week into this and I’m already jogging 8 minutes (sure, not in a row, but 8 minutes the 2nd week off the couch!).

Today I dragged my girlfriend along (she’s planning to run a 5k with me on Thanksgiving morning). Flor exercises regularly, but she is not a runner, yet she had no problem keeping up with me for these short intervals.

Of course I’m only a week into the schedule, and I’m sure it will get more challenging as the intervals get longer, but I’m pretty confident I’ll be able to keep up with the gradually increasing intensity.

So I encourage any of you who are attending RubyConf (or JRubyConf) to join us. We’ll have a website up with information and registration in a few weeks, but today is the day to start training! See you at the starting line!

Automating the Browser with Webrat and Selenium

This new chapter from Bryan Helmkamp shows you how to drive Cucumber scenarios right through your browser using Webrat and Selenium. You’ll type a single command and watch a browser fire up and walk through each scenario step by step right before your very eyes, and then see a standard Cucumber report in the shell. It’s a sight to behold, and a great way to drive out behaviour that requires JavaScript.

And now, for your reading pleasure …

Progress Report

I’m sure that all of you post-first-time authors out there know what I mean when I say that working on this book has been a fascinating case study in how not to write a book. First, we’re writing about not just one, but no less that six moving targets: RSpec, Cucumber, Rails, Webrat, Selenium and, of course BDD itself.

When we started this book, BDD was seen primarily as a new look at test driven development. The book was focused only on RSpec and TDD through this new lens. Had we stuck to that we might be talking about the third edition by now, but while we were writing, BDD was on the move.

BDD in 2009

Today, BDD has evolved to a full-stack agile process derived from Extreme Programming (XP). Rather than being a variation of TDD, it comprises TDD (and ATDP, DDD, etc, etc). And so has the book evolved to incorporate the application of these ideas to the practical use of an evolving toolset.

Also consider that four of the authors are primary maintainers of said moving targets (including BDD itself). Structuring a project like this leads to a different meaning of BDD entirely …

Book Driven Development

I can’t count the number of times that I’ve been writing about how to do something or set something up in RSpec or Cucumber and I’ve thought “Really? We could do better than that!” Each of those revelations led to software updates, followed by me poring through the book to update related content.

The end result is better software and a better book, benefiting RSpec and Cucumber users and The RSpec Book readers alike.

What remains to be done?

At this point we’re pretty close to the end of this journey. We’ve got two chapters left to write, plus some bookends (and beginnings - foreword, preface, and appendices). I also need to review pretty much everything because lots of things that we wrote about earlier in the process have changed.

After all that, we’ll have a final technical review, copyediting, indexing, and then off to print! So we’re in the final phases now and I look forward to reporting that the book is off to print in the not too distant future. How “not too distant” I hesitate to say, because so far I’m batting 000 in terms of release predictions (and I thought estimating software delivery was a challenge!).

In the mean time, I’ll be posting updates here as we progress, along with some discussion of the material in the book.

describe BowlingGame do
  it "scores all gutters with 0" do
    game = BowlingGame.new
    20.times { game.roll(0) }
    game.score.should == 0
  end
end

Then add second example:

describe BowlingGame do
  it "scores all gutters with 0" do
    game = BowlingGame.new
    20.times { game.roll(0) }
    game.score.should == 0
  end
 
  it "scores all 1's with 20" do
    game = BowlingGame.new
    20.times { game.roll(1) }
    game.score.should == 20
  end
end

Once we get the second example passing, we remove duplication in the examples, typically like this:

describe BowlingGame do
  before(:each) do
    @game = BowlingGame.new
  end
 
  it "scores all gutters with 0" do
    20.times { @game.roll(0) }
    @game.score.should == 0
  end
 
  it "scores all 1's with 20" do
    20.times { @game.roll(1) }
    @game.score.should == 20
  end
end

This last step involves copying the first line of each example to a before(:each) block, and then converting the references to game to an instance variable using an @ symbol. This is tedious and error prone, but we accept that in the interest of keeping things clean.

a convention emerges

One convention that has emerged over time is to introduce a helper method, like so:

describe BowlingGame do
  def game
    @game ||= BowlingGame.new
  end
 
  it "scores all gutters with 0" do
    20.times { game.roll(0) }
    game.score.should == 0
  end
 
  it "scores all 1's with 20" do
    20.times { game.roll(1) }
    game.score.should == 20
  end
end

With the first call to the game method in each example, ruby invokes the right side of the expression and stores it in the @game variable on the left, which is returned to the current and each subsquent caller. This approach takes up the same number of lines as the before(:each) block, but note the lack of @ symbols in the examples themselves.

Consider that there will likely be several more examples that have a similar structure, and you can see that the removal of @ symbols reduces a fair amount of noise. Not that there’s anything inherently wrong or noisy about instance variables, but for many this may just feel cleaner.

from convention emerges solution

Thanks to a suggestion from Stuart Halloway, rspec-1.2.9 introduces a new let() method that lets examples move towards @-less-ness by encapsulating the process of caching the instance variable. Here’s the previous example using let():

describe BowlingGame do
  let(:game) { BowlingGame.new }
 
  it "scores all gutters with 0" do
    20.times { game.roll(0) }
    game.score.should == 0
  end
 
  it "scores all 1's with 20" do
    20.times { game.roll(1) }
    game.score.should == 20
  end
end

The call to let() in this example defines a game method. The first time game is called in each example, it invokes the block, caches the result (an instance of BowlingGame), and returns it. Each subsequent call to game returns the same object, just like the game method in the previous example.

This will, admittedly, not change your life. Nor will it appeal to all of you, though I expect it to appeal to the lispier among you. The thing that I’ve noticed is that as more of these appear in a codebase, the more meaning they begin to establish, and it actually helps to compartmentalize this pattern and separate it from other helper methods that might be floating around.

So experiment away and please feel free to provide feedback here or on the rspec-users mailing list.

We’re using the new rubygems prerelease feature to do proper release candidates. This feature was introduced to rubygems a couple of versions back, but I’d recommend updating to rubygems-1.3.5 before installing the rspec prerelease gems.

For those unfamiliar with this new rubygems feature, you have to add the --prerelease flag in order to see and install these gems:

$ gem search --remote --prerelease rspec

  *** REMOTE GEMS ***

  rspec (1.2.9.rc1)
  rspec-rails (1.2.9.rc1)

$ [sudo] gem install --prerelease rspec
$ [sudo] gem install --prerelease rspec-rails

This way only those who choose to install the prerelease gems will get them, while those who exclude the –prerelease flag will get the previous final release (rspec-1.2.8, rspec-rails-1.2.7.1).

Once you install the prerelease gems, Rubygems will treat 1.2.9.rc1 as a higher version than 1.2.8, but a lower version than 1.2.9. That way when we do the final release you’ll be able to just install 1.2.9 and it will take its rightful place ahead of 1.2.9.rc1 without you having to uninstall rc1.

I invite you to install these prerelease gems and report any issues you run into to http://rspec.lighthouseapp.com/rspec. Advanced thanks to those who help the rest by breaking these in.

changes

Here are the changelogs for both rspec and rspec-rails. I’ll post separately about some of the new features in more detail.

rspec-1.2.9-rc1

• enhancements

  • manage backtrace-ignore patterns with Spec::Runner.configure (Martin Emde). Closes #870.
  • friendly mock argument expectation failure message (Tim Harper). Closes #868.
  • added double() as alias for stub() and mock()
  • failure messages for doubles, mocks and stubs use the right name
  • add let() method to assign memoized attributes (suggestion from Stuart Halloway). Closes #857.
  • add its method so you can say: describe Array do its(:length) { should == 0 } (Stephen Touset). Closes #833
  • spec command automatically uses spec/spec.opts if it is present (suggestion from Yehuda Katz)
  • rspec now adds PROJECT_ROOT/lib and PROJECT_ROOT/spec to the load path
  • determines PROJECT_ROOT by recursing up until it finds a directory that has a ./spec directory (thanks to Scott Taylor)
  • supports require ’spec_helper’
  • supports running specs from the PROJECT_ROOT or any directory below it
  • closes #733

• not really a bug fix or enhancement

  • temporarily moved heckle feature to features-pending (waiting to see what happens with http://rubyforge.org/tracker/index.php?func=detail&aid=26786&group_id=1513&atid=5921)

rspec-rails-1.2.9-rc1

• enhancements

  • added route_to and be_routable matchers (Randy Harmon). Closes #843.
  • Provide better failure message for render_template when redirected (Josh Nichols). Closes #885.
  • generated specs require ’spec_helper’

• bug fixes

  • pass the correct args to super in controller#render depending on the rails version (Lucas Carlson). Closes #865.
  • use Rack::Utils.parse_query to convert query strings to hashes. Closes #872.
  • errors correctly bubble up when a controller spec in isolation mode requests a non-existent action/template
  • no error if either action or template exist
  • error if neither exist
  • Closes #888.

• removals

  • spec_server has been removed in favor of spork.
  • You can still use the –drb flag, but you’ve got to install the spork gem.
  • Windows users who cannot use the spork gem can install the spec_server from http://github.com/dchelimsky/spec_server

• http://rspec.info

• http://rubyforge.org/projects/rspec
• http://github.com/dchelimsky/rspec
• http://github.com/dchelimsky/rspec-rails
• http://wiki.github.com/dchelimsky/rspec
• rspec-users@rubyforge.org
• rspec-devel@rubyforge.org

Last year I did a presentation about BDD and, with such a wide subject, ran out of time before I got through most of it. This year, the organizers of the conference have given me the opportunity to talk for three full hours! Count ‘em. Three!

It’s actually not just me talking (whew!). It’s a tutorial entitled Behaviour Driven Rails with RSpec and Cucumber. I’m planning an intensive skills development workshop, taking attendees through the development of a feature in a Rails app from planning to writing Cucumber scenarios to driving out code with RSpec. This is going to be about as close as you’ll get to a BDD immersion in three hours, so I hope to see you there whether you’re just learning about BDD now or you’ve already been doing it for a while.

See you in September!

Managing Complexity in Step Definitions

This chapter introduces a random generator to the Codebreaker game. This brings up several issues that can add complexity to Cucumber scenarios, RSpec code examples, and the code we’re driving out with the aid of these tools and the BDD process. We address these issues and offer strategies to manage the complexity they introduce.

Hello

We added a new chapter with basic install instructions and basic Hello Cucumber and Hello RSpec examples.

Rails Models

Covers writing model specs, validations, associations, mocks, test data builders and more.

Automating Features with Cucumber

We split Describing Features with Cucumber into two chapters: Describing Features with Cucumber and Automating Features with Cucumber. This allowed us to expand the material on planning the first release and iteration in the first chapter, and keep of the technical in the trenches material in the second.

Even if you’ve already read through the tutorial in previous beta releases, you’re going to want to re-read these two chapters.