[rspec-users] upgraded to rails 3.1.0 and found that string value of id has to be used instead of the integer value.

David Chelimsky dchelimsky at gmail.com
Tue Oct 25 08:54:32 EDT 2011

On Oct 25, 2011, at 1:56 AM, Gordon wrote:

> My advance apologies if the title/subject is not too descriptive.
> Pre: I have just upgraded from rails 3.0.9 to rails 3.1.0
> Before the upgrade, running 'rake spec' sees all my specs pass.
> After the upgrade, I seem to encounter some errors:
> -------------- Error extracts start -------------------------------
> controller_spec.rb ./spec/controllers/parts_controller_spec.rb
> ............................FFF
> Failures:
>  1) PartsController saves updates to an existing part object
> successfully by finding the existing part and returning it for update
>     Failure/Error: put :update, :id => "1", :part => {
>       <Part(id: integer, title: string, description: text,
> created_by: integer, updated_by: integer, created_at: datetime,
> updated_at: datetime) (class)> received :find with unexpected
> arguments
>         expected: (1)
>              got: ("1")
>     # ./app/controllers/parts_controller.rb:131:in
> `check_authorisation'
>     # ./spec/controllers/parts_controller_spec.rb:74:in `block (3
> levels) in <top (required)>'


> I can't think of a good reason of why putting the quotes worked after
> the upgrade to rails 3.1? It's worked fine all this while circa rails
> 3.1

I can, but not because it's an rspec issue. I just happened to submit the patch to Rails that made this change. [1]

The problem is that Rails functional tests, which power rspec controller specs, don't go through rack. This means that you used to be able to do this in a controller spec:

it "does one thing if :some_number is > 5" do
  get :some_action, :some_number = 6

And this in the controller:

def some_action
  if params[:some_number] > 5

And the spec would pass, but it would fail when running through rack, as it does when you run a server. That's because all parameters are 'to_param'd before they make it to a controller when running through rack, but they weren't getting the same treatment in Rails functional tests. This was true whether you were using rspec, minitest, test/unit, etc, and was happening because the Rails test framework was letting Fixnums in the specs make it directly to the controllers.

So the upside of this change is that we decrease the likelihood of false positives. The downside is that you have to change stubs and message expectations that are constrained on non-strings to expect strings. The upside of the downside is that your specs are now telling the truth, and are correctly aligned with the reality of the running application.


[1] https://github.com/rails/rails/pull/1203

> Why should I have to pass a string of '1' instead of using the integer
> value, 1 of the id to the stubbing definition for the find method (As
> argument) and the expected id value in the should_receive test?
> Would like to hear some thoughts on this behaviour.
> Thank you
> Gorodn Yeong

More information about the rspec-users mailing list