Let’s say we were creating an API that allows us to create ‘foo’s. Foos, as far as we know, will have a first name and a title. We can write a request spec to help us drive out our endpoint’s behavior:

Right off the bat, it’s not entirely obvious what we’ve missed. Did we forget to do something in the database? In the model? In the controller? While finding the issue is not “Where’s Waldo”-tier, our test is providing us with some pretty weak feedback. Given that this is an integration test, the problem is that we’ve most likely wired something up incorrectly. If we check our test.log, hidden in between the request and our database logs is the culprit:

As we are oft to do, we forgot to whitelist the :title parameter, and so the parameter is being completely ignored:

def foo_params
params.require(:foo).permit(:first_name)

Ideally our test would tell us that we’ve made a mistake wiring up our code, rather than the ambiguous error we’re getting. We can make our tests give us better feedback by reconfiguring Rails to throw an error when given unauthorized attributes. In config/environments/test.rb we can add the line:

Rails.application.configure do
... # some other config
config.action_controller.action_on_unpermitted_parameters = :raise
... # some other config
end

Our test failure reveals the exact line in our code where we’ve misconfigured our app. In the future, it will be obvious when we inevitably make this mistake again. Further, this change will highlight places in our (tested) code where we’ve been sending parameters that haven’t been whitelisted.