David Chelimsky

full changelog

• Bug fixes
  • respond_to? correctly handles 2 args
  • scaffold generator no longer fails on autotest directory

Slides from my RubyConf 2010 talks in São Paulo, Montevideo, and New Orleans:

Maintaining balance while reducing duplication

I just released rspec-1.3.1 and rspec-rails-1.3.3.

These are mostly bug fixes that have been sitting around for all to long as I focused on rspec-2 (coming very soon).

Report issues for rspec[-rails]-1.x to https://rspec.lighthouseapp.com/projects/5645.

Docs:

http://rspec.info/
http://rdoc.info/gems/rspec/1.3.1/frames
http://rdoc.info/gems/rspec-rails/1.3.3/frames

Cheers, David

rspec-1.3.1 / 2010-10-09

• enhancements

  • Array =~ matcher works with subclasses of Array (Matthew Peychich & Pat Maddox)
  • config.suppress_deprecation_warnings!

• bug fixes

  • QuitBacktraceTweaker no longer eats all paths with ‘lib’ (Tim Harper - #912)
  • Fix delegation of stubbed values on superclass class-level methods. (Scott Taylor - #496 - #957)
  • Fix pending to work with ruby-1.9

• deprecations

  • share_as (will be removed from rspec-core-2.0)
  • simple_matcher (will be removed from rspec-core-2.0)

rspec-rails-1.3.3 / 2010-10-09

• enhancements

  • replace use of ‘returning’ with ‘tap’

• bug fixes

  • support message expectation on template.render with locals (Sergey Nebolsin). Closes #941.
  • helper instance variable no longer persists across examples (alex rothenberg). Closes #627.
  • mock_model stubs marked_for_destruction? (returns false).

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