Functional Testing Annoyances, Wapcaplet, And You

Noel Rappin, Friday, August 7, 2009 @ 3:45 pm

Here's a minor thing that bugs me all the time.

I'm writing a functional test:

should "do something functional"
  get :search,  rder_id => @order.id, :user_id => @user.id
  # and so on
end

The get call in that test simulates a browser request. Intuitively, you would (well, I would) expect this request to be identical to a request coming from the actual view, via a helper like link_to("search", :action => :search, rder_id => @order.id, :user_id => @user.id). At least, you'd expect that parameters hash in the controller to be the same between the

Makes sense, right? The testing call should set up the same environment as the actual call being tested.Well, if you've gotten this far, read the title that said "Annoyances", or have ever read any blogs, you know that isn't how Rails works. Specifically, the actual browser call has all its arguments converted to strings as part of going through the HTTP wire, but Rails, oddly, does not similarly convert the arguments in the test.

Most of the time it makes no difference -- if you pass the string or the integer directly to an ActiveRecord find method, everything works swimmingly. If you do a direct equality check on the parameter, though, you can get code that passes tests, but fails in the browser because the string value is no longer equal to the integer value.

For some time, I've had this on my list of annoyances that I don't have the energy to fix, right next to the slightly misaligned light over my desk, and the fact that they bought the wrong kind of Kleenex at the office that one time.

This week, Adam Milligan at Pivotal Labs tried to do something about it. Specifically, he created a Rails patch, then a plugin, that can raise a warning or an error when a non-string argument is passed to an HTTP method in a functional test.

Adam chose to fail or warn rather than silently convert the parameter because he feels that some arguments that might get placed in an HTTP method don't have clear correct conversions (his example is false), and he's trying to avoid setting up a whole different kind of difficult-to-diagnose test to app misalignments.

As much as I love that Adam did this, I kind of think that it's more consistent with Rails design to silently convert, to make the browser call and the test consistent. Still, having the code warn or fail (your choice) is a pretty good way to get into good habits and avoid having to track down weird test errors. So, thanks, Adam.

Related Services: Ruby on Rails Development, Custom Software Development

Related posts:

1. Rails, Ajax, RJS, and Testing
2. Rails Testing First Look: Blue Ridge
3. Elements of Testing Style
4. The Testing Interviews
5. Using Cucumber for Acceptance Testing

Comments (1)

Software Development

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I think you need to turn off the emotiocons.

   Comment by John Miller, Friday, August 7, 2009 @ 5:57 pm

Leave a comment