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.