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)>'
<snip/>
> 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
end
And this in the controller:
def some_action
if params[:some_number] > 5
do_this
else
do_that
end
end
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.
HTH,
David
[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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
