December 16th, 2010
- Bug fixes
- respond_to? correctly handles 2 args
- scaffold generator no longer fails on autotest directory
November 13th, 2010
Slides from my RubyConf 2010 talks in São Paulo, Montevideo, and New Orleans:
October 9th, 2010
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.
rspec-1.3.1 / 2010-10-09
- Array =~ matcher works with subclasses of Array (Matthew Peychich & Pat Maddox)
- 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
- 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
- replace use of ‘returning’ with ‘tap’
- 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).
July 11th, 2010
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?
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.
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
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
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
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:
[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.
June 28th, 2010
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.
June 17th, 2009
We added a new chapter with basic install instructions and basic Hello Cucumber and Hello RSpec examples.
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.
June 8th, 2009
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‘
Even if you’re not using RSpec, you’ll get ZenTest’s
autotest/autotest.rb instead of
autotest/rails.rb when you run the
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.
March 30th, 2009
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.
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.