2013-05-15 18 views
12

Używam klejnotu strong_parameters w moich kontrolerach, ale ciężko mi zrozumieć, jak go przetestować.RSpec - Testowanie mocnych parametrów

Oto przykład z mojej konfiguracji

class UserController < ActionController::Base 
    include ActiveModel::ForbiddenAttributesProtection 

    def create 
    @user = User.new(user_params) 
    if @user.save 
     ... 
    end 
    end 

    private 
    def user_params 
    params.require(:user).permit(:first_name, :last_name, :username, :email) 
    end 
end 

Chcę przetestować metodę user_params, aby upewnić się, że jest prawidłowo odfiltrowanie par klucz/wartość szkodliwe, ale nie można dowiedzieć się, jak to zrobić. Czy ktoś jeszcze przez to przeszedł?

Odpowiedz

14

Można skrótową hash params jako

params = ActionController::Parameters.new(your_hash) 

Jest to klasa, że ​​params URL są przekształcane w kontrolerze, a to daje wymagające i pozwalają metod.

Osobiście rozpakowuję funkcjonalnie do nowej klasy, aby obsłużyć politykę autoryzacji.

0

Nie jestem pewien, czy przetestowałbym strong_parameters, który domyślam się używasz przez the gem.

Klejnot ma its own tests, więc możemy założyć, że działa zgodnie z oczekiwaniami.

To jest przykład "testowania szyn", który uważam za niepotrzebny. Nie przetestowałbym, czy attr_accessible działa tak jak w reklamie (Testing Rails) lub attr_accessor (Testowanie Ruby).

IMHO, twoje testy integracyjne powinny obejmować wszystkie pożądane instancje sukcesu/niepowodzenia i domyślnie obejmować konfigurację strong_parameter.

+3

Nasza polityka test jest jawnie pisać testy dla wszystkich funkcji, aby umożliwić nam potencjalnie przełączaj klejnoty/zwiń nasze własne później i nadal wiedz, że system działa. – Bryce

+10

Możesz również sprawdzić, czy twój kod integrujący się z parametrem strong_parametres działa poprawnie. Mam pola, które można zapisywać/nie można zapisywać w zależności od ról użytkownika/uprawnień, więc muszę przetestować, czy te dwa elementy są poprawnie zintegrowane. – cpuguy83

+1

Po pobraniu aplikacji z Rails 1.1 do 3.2 (a teraz przygotowując się do 4.0), mogę zapewnić, że testowanie Railsów jest bardzo potrzebne. Coś, co działa w jedną stronę w jednej wersji Railsów, może zmienić zachowanie w innej wersji. Na przykład kiedyś sklonowałem rekordy rekordów aktywnych za pomocą metody 'clone', ale gdzieś pomiędzy wersją 3.0 a 3.2 zdecydowano, że' dup' zapewni tę funkcję zamiast ... i zrobi to nieco inaczej. To nie było dobrze reklamowane, ale szybko zostały przechwycone przez moje testy. – sockmonk

5

zmodyfikować to w zależności od potrzeb,

describe "create action" do 
    it 'creates a user' do 
     User.should_receive(:create). 
     with({name: 'Alan D'}.with_indifferent_access) 
     post :create, user: 
     { first_name: 'Alan', last_name: 'Donald', username: 'alan77', email: '[email protected]' } 
    end 
end 

lub inne alternatywne rozwiązanie tego problemu jest:

describe UsersController::UserParams do 
    it 'cleans the params' do 
    params = ActionController::Parameters.new(user: {foo: 'bar', name: 'baz'}) 
    user_params = UsersController::UserParams.build(params) 
    expect(user_params).to eq({name: 'baz'}.with_indifferent_access) 
    end 
end 
Powiązane problemy