RSpec-2.0.0.beta.22 is released!
September 12th, 2010
We’re getting very close to a 2.0 release candidate, so if you’re not already using rspec-2 (with or without rails-3), now is the time to start. I need your feedback, so from here on in I’ll be sending out announcements and release notes for each beta release.
As for rspec-2 with rails-2, there are a few efforts underway to make that work, but that will be in the form of a separate gem and our priority is getting rspec-2 out the door.
Please report issues or submit pull requests (yes, pull requests are fine now that github has integrated them so well with issues) to the appropriate repos:
- http://github.com/rspec/rspec-core/issues
- http://github.com/rspec/rspec-expectations/issues
- http://github.com/rspec/rspec-mocks/issues
- http://github.com/rspec/rspec-rails/issues
Here are release notes for each gem in this beta release, drawn from the nascent History.md files in each project.
rspec-core-2.0.0.beta.22 / 2010-09-12
Enhancements
- removed at_exit hook
- CTRL-C stops the run (almost) immediately
- first it cleans things up by running the appropriate after(:all) and after(:suite) hooks
- then it reports on any examples that have already run
- cleaned up rake task
- generate correct task under variety of conditions
- options are more consistent
- deprecated redundant options
- run ‘bundle exec autotest’ when Gemfile is present
- support ERB in .rspec options files (Justin Ko)
- depend on bundler for development tasks (Myron Marston)
- add example_group_finished to formatters and reporter (Roman Chernyatchik)
Bug fixes
- support paths with spaces when using autotest (Andreas Neuhaus)
- fix module_exec with ruby 1.8.6 (Myron Marston)
- remove context method from top-level
- was conflicting with irb, for example
- errors in before(:all) are now reported correctly (Chad Humphries)
Removals
- removed -o –options-file command line option
- use ./.rspec and ~/.rspec
rspec-expectations-2.0.0.beta.22 / 2010-09-12
Enhancements
- diffing improvements
- diff multiline strings
- don’t diff single line strings
- don’t diff numbers (silly)
- diff regexp + multiline string
Bug fixes
- should[_not] change now handles boolean values correctly
rspec-mocks-2.0.0.beta.22 / 2010-09-12
- Bug fixes
- fixed regression that broke obj.stub_chain(:a, :b => :c)
- fixed regression that broke obj.stub_chain(:a, :b) { :c }
- respond_to? always returns true when using as_null_object
2.0.0.beta.22 / 2010-09-12
Enhancements
- autotest mapping improvements (Andreas Neuhaus)
Bug fixes
- delegate flunk to assertion delegate
The RSpec Book has entered the production process!
July 30th, 2010
I’m thrilled to announce that The RSpec Book has entered the production process!
For those of you unfamiliar with the publishing industry, as I was before this project, “has entered the production process” does not mean that it’s off to the printer. What it does mean is that it is currently being indexed so readers will be able to find the stuff they’re looking for. After indexing it will be copyedited (in which someone with better grammar and spelling than any of the authors possess makes the book more readable) and typeset, and then off to the printer.
If all goes to plan (yes, there actually is a plan!), books.should be_on_shelves in late September, early October.
That light at the end of the tunnel is, finally, not an oncoming train!
RSpec-2 Documentation
July 1st, 2010
RSpec-2 is getting close to a release candidate, and as the beta gems have been flowing a lot of questions have been coming in, especially about documentation. Here is some information that should help.
Source code
RSpec development has moved to the rspec account on github. There are five repositories at the moment:
- http://github.com/rspec/rspec
- http://github.com/rspec/rspec-core
- http://github.com/rspec/rspec-expectations
- http://github.com/rspec/rspec-mocks
- http://github.com/rspec/rspec-rails
rspec-rails depends on rspec, which depends, in turn, on the other three.
This structure has many benefits, but one cost is that the documentation, though plentiful, is a bit scattered.
READMEs
- http://github.com/rspec/rspec
- http://github.com/rspec/rspec-core
- http://github.com/rspec/rspec-expectations
- http://github.com/rspec/rspec-mocks
- http://github.com/rspec/rspec-rails
Upgrade Notes
- http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown
- http://github.com/rspec/rspec-expectations/blob/master/Upgrade.markdown
- http://github.com/rspec/rspec-rails/blob/master/Upgrade.markdown
Cucumber features
Each of the repos has a growing set of Cucumber features. Some of the features have been added in after the fact, but many of the new features have been driven out using Cucumber. These are a great source of “How-To” information, and you know they’re up to date because they are executable documentation.
If you peruse these and are unable to find the information you’re looking for, or find any of the information incomplete or confusing, please, please, please submit a github issue (see Known Issues, below). Or, better yet, submit a patch!
- http://github.com/rspec/rspec-core/tree/master/features/
- http://github.com/rspec/rspec-expectations/tree/master/features/
- http://github.com/rspec/rspec-mocks/tree/master/features/
- http://github.com/rspec/rspec-rails/tree/master/features/
RDoc
The RDoc is arguably the weakest link here. Patches welcome!
- http://rdoc.info/projects/rspec/rspec-core
- http://rdoc.info/projects/rspec/rspec-expectations
- http://rdoc.info/projects/rspec/rspec-mocks
- http://rdoc.info/projects/rspec/rspec-rails
Known Issues
Issues for rspec-2 are being maintained on github.
- http://github.com/rspec/rspec-core/issues
- http://github.com/rspec/rspec-expectations/issues
- http://github.com/rspec/rspec-mocks/issues
- http://github.com/rspec/rspec-rails/issues
If you want to submit an issue and you’re not sure which tracker it belongs in, just pick the one you think is most appropriate. I’m more interested in getting the feedback then you knowing where to put the issue. I’ll move it to the right place if necessary.
Wikis
PLEASE NOTE: github wikis can be updated by anybody with a github account, and I don’t get any notification when wiki pages have changed. Most of the time, users add valuable information, but the structure is poor and always in flux, and there have been occasions in which the information was either misleading or simply inaccurate. The Cucumber features mentioned above, though currently incomplete, are a much better source for accurate documentation.
- http://wiki.github.com/rspec/rspec/
- http://wiki.github.com/rspec/rspec-core/
- http://wiki.github.com/rspec/rspec-expectations/
- http://wiki.github.com/rspec/rspec-mocks/
- http://wiki.github.com/rspec/rspec-rails/
The RSpec Book
The RSpec Book is being updated for RSpec-2 and Rails-3. There will still be references back to RSpec-1 and Rails-2 where things have changed, but the focus will be on the way forward. Once the rails-3 and rspec-2 release candidates are out, we’ll release one more updated PDF of the book for those in the beta program, and then off to the printer it goes. FINALLY!
The RSpec Book — Beta 10 and Progress Report
September 23rd, 2009
Beta 10????? When the hell are we going to start chopping down some trees? Well, first, here’s what’s new in Beta 10 of The RSpec Book:
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 … Read the rest of this entry »
Windy City Rails
July 18th, 2009
I’m presenting at Windy City Rails in September. This is just the second year of this exciting midwest Rails conference, but the schedule looks most impressive. Talks range from How To Test Absolutely Anything to Better Ruby through Functional Programming to a Rails 3 Update from Yehuda Katz, Rails core’s newest member and the man who is bringing the best of Merb to Rails 3.
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!
tutorial - rspec: stubs and mocks
November 9th, 2006
RSpec’s mocking/stubbing facilities are enhanced significantly in RSpec-0.7.
You can now intermingle stub methods and mock expectations on the same objects. This applies to instances of Spec::Mocks::Mock or ANY other object or class.
Having integrated stubs and mocks available not only supports isolated and fast controller specs, it also provides a nice way to separate setup noise from the “interesting bits” in your specs. I try to exploit this by preferring stub methods (stub!) in my setup and mock expectations (should_receive) in specify blocks.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
context "the PersonController" do controller_name :person setup do @person = mock("person") Person.stub!(:new).and_return(@person) end specify "should create a new person on GET to create" do Person.should_receive(:new).and_return(@person) get 'create' end specify "should assign new person to template on GET to create" do get 'create' assigns[:person].should_be @person end specify "should render 'person/create' on GET to create" do controller.should_render :template => "person/create" get 'create' end end |
In this example, the line …
Person.stub!(:new).and_return(@person)
… in setup stubs the method so GET ‘create’ will work every time. The line …
Person.should_receive(:new).and_return(@person)
… in the specify block “should create a new person on GET to create” sets an expectation that must be met. Even though it seems like duplication of the stub method, it is serving a different function: it tells the story for that spec.
Note how in the other specs there is no focus on Person.new. It’s out of the way, but the stub in the setup makes sure its taken care of.
So use stubs to take care of the “noise” (in this case stuff that has to be there to get the specs to run), and use mock expectations to put focus on the fact that something is expected.

