David Chelimsky

Some questions have come up since I posted about rspec-rails-2 generators and rake tasks requiring that rspec-rails be declared in the :development group in a Gemfile. Here are a few of them, paraphrased, with answers:

Why the change?

rspec-rails now uses a Railtie to expose the rake tasks and generators. Railties allow Rails extensions to register themselves with Rails without having to copy files into your app. This makes installation and, especially, upgrades much easier to manage for both maintainers and users.

Do I need rspec-rails in both :development and :test groups?

:development

We need rspec-rails in the :development group in order to expose the rake tasks and generators without having to type RAILS_ENV=test when we want to use them.

:test

Quite ironically, it turns out that we don’t need it in the :test group at all. That may change in the future, and I don’t see any harm in keeping it in the :test group as well, so I’ll probably keep it there in my apps.

Doesn’t that mean I’m loading rspec-rails and all of its dependencies in the :development environment?

No, and herein lies the benefit of using a Railtie for this.

When you declare a gem in a Gemfile, Bundler loads up a file with the same name as the gem, in our case rspec-rails.rb.

The generator configs are only invoked when running rails generate, which is when you want them. The require statement is only invoked when running rake, which is when you want it. If you’re not running rake or rails generate, then no other files from rspec-rails or any of its dependencies are loaded, unless you load them explicitly from elsewhere in your app.

Does this actually work? When I add rspec-rails to the :development group and run rails generate, I don’t see most of the rspec generators.

The only RSpec generator that is intended to be invoked directly is rspec:install, which you’ll still see. The others are invoked implicitly by Rails when you run the various Rails generators. e.g., if you run script/rails generate controller Widgets, the controller generator implicitly calls out to the rspec:controller generator to generate a WidgetsController spec.

Because these are intended to be implicit, Rails hides them from you in order to reduce the noise level.

OK, but now I see all of the test_unit generators. What’s up with those?

Because RSpec is the test framework of record, Rails doesn’t know to hide the test_unit generators. If you want to hide them, just add this to one of your config files:

Rails::Generators.hide_namespace("test_unit")

[Updated on 7//14]

Turns out that hide_namespaces doesn’t work for this use case. I’ve got an open ticket in the Rails tracker to address this, and I’ll updated this post again once it’s addressed.

View isolation is changing in rspec-rails-2. As of beta.14, the view template needs to exist, but the content of the template will not be evaluated. This still provides isolation from the content of the template and its dependencies, it just means the file has to be there, which means you have to create it.

Why this change?

rspec-rails-1 performed some serious gymnastics to isolate controller specs from views. As many rspec/rails users well know, all the monkey patching of Rails’ internals led to rspec-rails releases immediately following rails releases.

Thankfully, Rails 3 exposes very clean extension points and APIs that make it far simpler to get the most important part of this isolation: isolation from the content of the template.

Rails 3 Resolvers

Rails makes a number of decisions based on the existence or lack thereof of a given template on the file system. Rails 3 also supports custom resolvers that let you store view templates in a database, for example. Given the wide array of possibilities, it is not possible for RSpec to predict every way in which templates will be stored or accessed.

What RSpec can do, and does as of beta.14, is use the Rails machinery, or custom extensions that adhere to the Rails Resolver API, to find and load templates, and then stub out the content. Doing so requires much less code and, more importantly, much less invasive code. This increases the likelihood that new features in Rails will just work with rspec-rails as it is, and decreases the likelihood that changes to Rails’ internals will require rspec-rails to release updates with every new release of Rails.

When contributing to a git(hub)-hosted open source project, it is often recommended that you follow these steps:

• fork the repo
• make changes on a topic branch
• push the branch to your repo
• send a pull request or link to the commit from a ticket

I was recently asked whether the topic branch in step 2 was necessary. The answer is that it’s not really necessary, it just makes life easier for both the contributor and the maintainer. Here’s why.

When maintainers merge patches, they often modify commit messages: rewording for consistency in the commit logs, sign-off statements, etc. They’ll also sometimes change the actual content of the commit to fix typos, reorganize methods in a file, etc, etc.

In either case, the result is that the commit that gets merged to the mainline repo has a different sha1 than the commit you submitted. This means that when you go to merge the mainline master branch back into your master branch, you’ll run into conflicts. Then, if you resolve them, the HEAD of your master branch is not the same as the HEAD of the mainline master branch, so the next patch you submit off your master branch will likely not apply easily.

By keeping your patches on topic branches, you’re able to keep your master branch aligned with the mainline master branch. This makes it easier for you to submit more patches later. It also makes it more likely that your contributions will apply cleanly, which increases the likelihood that they’ll be accepted.

The RSpec Book Beta 6.0 was just released. This release includes a number of fixed errata, two new chapters, and a bit of re-organization.

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.

If you use Autotest with Ruby on Rails, be sure to gem install autotest-rails when you upgrade to ZenTest-4.1.0.

Without that gem, when you run the autospec command that ships with RSpec, Autotest won’t won’t have any way of knowing it’s in a Rails app and it will load up rspec’s autotest/rspec.rb instead of rspec-rails‘ autotest/rails_rspec.rb.

Even if you’re not using RSpec, you’ll get ZenTest’s autotest/autotest.rb instead of autotest/rails.rb when you run the autotest command.

The next release of rspec-rails will include a patch to resolve this for RSpec users, but in the mean time (and for everybody else), just gem install autotest-rails and resume your regularly scheduled continuous testing.

We’ve released version 3.0 of The RSpec Book beta. It’s got a number of improvements per suggestions submitted by readers, as well as two new chapters.

New Chapter: Evolving Existing Features

This is the next chapter in the Mastermind tutorial, in which we take the reader through the process of developing a command line version of the classic Mastermind game. In this chapter, we explore the problem of driving out changes to existing behaviour with new scenarios and code examples, all the while keeping the old code examples passing.

New Chapter: The Case for BDD

As the title suggests, this chapter lays out the case for Behaviour Driven Development as an over-arching methodology. You’ll read about how and why so many traditional projects fail, the Agile Manifesto and the methodologies that emerged around it, and why so many teams continue to struggle in spite of best efforts to adopt these new methodologies.

Thanks

Many thanks to all of you who are already participating in The RSpec Book beta program and making so many great suggestions. Your contribution to this process is invaluable for the book and all of its readers.

rspec-1.2.0 and rspec-rails-1.2.0 have been released!

You’ll need this upgrade if you’re upgrading to rails-2.3.

Be sure to read the change logs before upgrading. There have been a few changes that will impact some (not all) of you.

rspec-1.2.0: RDoc | History
rspec-rails-1.2.0: RDoc | History

Better late than never:

[david: rspec (master)]$ multiruby -S rake spec
...
Passed: v1_8_6_114, 1.8.7-p72, 1.9.1-p0


[david: example_rails_app (master)] $ multiruby -S rake rspec:pre_commit
...
Passed: v1_8_6_114, 1.8.7-p72, 1.9.1-p0

Coming soon to a gem release near you.

The Pragmatic Programmers have just released the The RSpec Book, Beta 2.0. If you’ve already purchased the beta book, you can go to your account page and you’ll be able to download the new update.

If you haven’t purchased the beta book yet, now is a great time to join the party! We just added three new chapters:

Evolving Requirements

This is the next chapter in the Mastermind tutorial, which takes you through the evolution of a command line version of the classic Mastermind board game. The earlier chapters introduce RSpec and Cucumber. This new chapter introduces Cucumber’s new Scenario Outlines feature, which let’s you express repetitive scenarios in FIT-inspired tabular format.

Simulating the Browser with Webrat

Bryan Helmkamp, Webrat’s lead maintainer, builds on the Cucumber/Rails material in earlier chapters, driving those scenarios through the Rails stack with Webrat’s simple, powerful API.

Rails Views

Zach Dennis shows you how to write RSpec code examples for Rails views. Using Webrat’s have_xpath and have_selector matchers, and wrapping them in custom matchers targetted at your app, Zach shows you how to provide value throughout the life of the application with expressive, maintainable view specs.

Chapters from Beta 1.0

These new chapters build on the chapters we already released in Beta 1.0:

• Introduction
• Describing Application Behaviour with Cucumber
• Working from the Outside-In with RSpec
• Code Examples
• Expectations
• RSpec and Test::Unit
• Tools and Integration
• BDD in Rails
• Cucumber with Rails

Up Next

We’ve got many more chapters coming over the next two or three updates, including chapters from Dan North and Dave Astels on Behaviour Driven Development and Mock Objects, new material on integrating Selenium, extending and customizing RSpec, and much, much more.

Thanks to all who are already participating in the beta program. We’ve gotten some great feedback so far. Some of it is already incorporated in the 2.0 beta release, and much more will be addressed in the upcoming releases. You’re all making this a better book for everyone else who will read it, so thank you, thank you, thank you.

Thank you to all who are participating in The RSpec Book beta program. We’ve already gotten some good feedback, and we look forward to more as we release updates over the coming weeks.

For those of you who are reading the beta and would like to provide feedback, there are two outlets for you on the Pragmatic Programmers’ site.

The errata page is for technical errors, typos, etc. Things that don’t really require any discussion and are simple, task oriented fixes.

Although the errata page lists Suggestion as a type of errata, the system provides no opportunity for a conversation. Therefore, if you are making a comment like “I’m not sure I agree with the statement on page 37” or “you say x here and y there, which is it?”, etc, then the forum might be a better option. That way I (or any of the authors) can throw questions back at you to get a better feel for what you’d like to see and how it might help.

Of course, we’d rather have your feedback than not, so if you’re not interested in such a dialog, go ahead and stick to the one-way-street of the errata page.

Again, thanks for the feedback thus far. You’re helping to make this a better book for everyone else who will read it.