My Migration Pains to RSpec 0.9.x from 0.8.x : Intractable Complexity

My Migration Pains to RSpec 0.9.x from 0.8.x

The upgrade guide to 0.9.x should definitely be followed, but in addition to that, I give you a modest list of gotchas that happened to burn me:

Assigns are only set when using get|post|put|delete|head methods in controllers
A bug with the --drb option runs tests twice (patch available)
Spec::Rails::Runner::EvalContext is now Spec::Rails::DSL::EvalContext
Exceptions inside controller actions can no longer be caught in the specs

Assigns are only set when using `get|post|put|delete|head` methods in controllers

I used to have separate tests for my application filters ran via controller.send :my_filter. I still think this is a good idea. Unforunately, as of 0.9 RSpec will no longer set the assigns hash unless you actually perform a simulated http operation (get, post etc), so you can no longer check if an assigns was set just using assigns. It can still be done by grabbing the instance var directly from the controller however.

court3nay suggested making a helper:

# spec/spec_helper.rb
module Spec
  module Rails
    module DSL
      class FunctionalEvalContext
        def ivars(ivar_name)
          instance_variable_get(("@"+ivar_name.to_s).to_sym)
        end
      end
    end
  end
end

So,

controller.send :run_filter
assigns[:filter_ran].should be_true # no longer works in 0.9.x

becomes:

controller.send :run_filter
ivars(:filter_ran).should be_true # works!

A bug with the `--drb` option runs tests twice (patch available)

`Spec::Rails::Runner::EvalContext` is now `Spec::Rails::DSL::EvalContext`

Adding methods / including modules to EvalContext and friends (there is also ControllerEvalContext just for contorllers, FunctionalEvalContext for controllers AND views, and more) allows you to make certain methods available in all your specs – very handy for application specific helper methods and/or custom matchers.

module Spec
  module Rails
    module Runner
      class EvalContext
        include MyCustomMatchers
        def my_handy_helper
           #...
        end
      end
    end
  end
end

becomes: module Spec module Rails module DSL class EvalContext include MyCustomMatchers def my_handy_helper #... end end end end end

this is so people can test their various error handlers. I happened to use this behavior to forcefully stop execution when certain filters were called (in retrospect, probably a bad idea).

Intractable Complexity