Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Testing Strong Parameters – Redux

With the flurry of new features introduced in Rails 4 I was interested in how they would affect every day developer life here at Pivotal Labs. Luckily one of my fellow Pivots Robbie Clutton had decided to dive in and investigate testing strong paramters.

On my previous project we had already adopted strong parameters on a Rails 3.2 codebase and hadn’t come up with a pattern we particularly liked. Seeing real promise in the technique Robbie suggested I decided to give it a go. Unfortunately we ran into a snag when using update_attributes when overriding the ActionController::Parameters constructor as suggested.

It turns out that under the hood update_attributes dups the object, creating a new instance with the filtered params. If you happened to slice your params in the constructor using require you will no longer have the top level key user. This results in a ActionController::ParameterMissing: param not found: user exception.

So in the spirit of standing on the shoulders of those that came before, I give you the modifications we came up with.

class UsersController < ApplicationController

   def update
      user = User.find(params[:id])

      respond_with user

   class UserParams
      def self.permit params
         permit(:first_name, :last_name)

And the updated spec

describe UsersController::UserParams do
    describe ".permit" do
      it "returns the cleaned params" do
        user_params = { first_name: "Kanye", last_name: "West" }
        params = { foo: "foo" }.merge(user_params))

        permitted_params = UsersController::UserParams.permit(params)
        expect(permitted_params).to eq(user_params.with_indifferent_access)

  1. Why keep it a subclass of ActionController::Parameters?

    Additionally, this is almost in the realm of testing configuration instead of functionality. It smells of `it { should have_many :associations }`.

  2. Alex Kwiatkowski says:

    Samuel you make a good point about not inheriting from from ActionController::Parameters. There is no need so I’ve updated the post.

    Can you expand on how you think this is testing configuration? What other mechanism would you use to test the authorized parameters?

  3. Giles Bowkett says:

    Those are really two separate questions.

    I just built a spec based on this approach, with some minor changes, and it felt very much like testing configuration. I actually blame Rails; when you write a method or a class to specify which parameters are allowed or disallowed, it feels to me very much like writing a method to configure security. At the least, I’d prefer the most common use case to be wrapped in a class method, since it seems to happen quite a lot.

    With that in mind, the other method I’d probably use would be to write a test for that class method, write the method itself, package it in a gem, and then make that gem a standard adjunct to my use of Rails. Since you guys posted this a year ago, though, I think odds are pretty good somebody already has.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *