ruby on rails - pruebas - Cómo probar una preocupación del controlador en Rails 4

rspec español

Question

¿Cuál es la mejor manera de manejar las pruebas de problemas cuando se usa en los controladores Rails 4? Digamos que tengo una preocupación trivial Citations .

module Citations
    extend ActiveSupport::Concern
    def citations ; end
end

El comportamiento esperado bajo prueba es que cualquier controlador que incluya esta preocupación obtendría este punto final de citations .

class ConversationController < ActionController::Base
    include Citations
end

Sencillo.

ConversationController.new.respond_to? :yelling #=> true

Pero, ¿cuál es la forma correcta de probar esta preocupación aisladamente?

class CitationConcernController < ActionController::Base
    include Citations
end

describe CitationConcernController, type: :controller do
    it ''should add the citations endpoint'' do
        get :citations
        expect(response).to be_successful
    end
end

Lamentablemente, esto falla.

CitationConcernController
  should add the citations endpoint (FAILED - 1)

Failures:

  1) CitationConcernController should add the citations endpoint
     Failure/Error: get :citations
     ActionController::UrlGenerationError:
       No route matches {:controller=>"citation_concern", :action=>"citations"}
     # ./controller_concern_spec.rb:14:in `block (2 levels) in <top (required)>''

Este es un ejemplo artificial. En mi aplicación, recibo un error diferente.

RuntimeError:
  @routes is nil: make sure you set it in your test''s setup method.

Answer 1

Encontrarás muchos consejos que te dicen que uses ejemplos compartidos y los ejecutes en el alcance de tus controladores incluidos.

Personalmente, considero que es excesivo y prefiero realizar pruebas unitarias de forma aislada, luego uso pruebas de integración para confirmar el comportamiento de mis controladores.

Método 1: sin enrutamiento o prueba de respuesta

Crea un controlador falso y prueba sus métodos:

describe MyControllerConcern do

  before do
    class FakesController < ApplicationController
      include MyControllerConcern
    end
  end
  after { Object.send :remove_const, :FakesController }
  let(:object) { FakesController.new }

  describe ''my_method_to_test'' do
    it { expect(object).to eq(''expected result'') }
  end

end

Método 2: prueba de respuesta

Cuando su inquietud contiene enrutamiento o necesita una prueba de respuesta, representación, etc., debe ejecutar su prueba con un controlador anónimo. Esto le permite obtener acceso a todos los métodos y ayudantes de rspec relacionados con el controlador:

describe MyControllerConcern, type: :controller do

  controller(ApplicationController) do
    include MyControllerConcern

    def fake_action; redirect_to ''/an_url''; end
  end
  before { routes.draw {
    get ''fake_action'' => ''anonymous#fake_action''
  } }


  describe ''my_method_to_test'' do
    before { get :fake_action }
    it { expect(response).to redirect_to(''/an_url'') }
  end
end

Puede ver que tenemos que ajustar el controlador anónimo en un controller(ApplicationController) . Si tus clases son heredadas de otra clase que ApplicationController , necesitarás adaptar esto.

Además, para que esto funcione correctamente, debe declarar en su archivo spec_helper.rb :

config.infer_base_class_for_anonymous_controllers = true

Nota: siga probando que su preocupación está incluida

También es importante probar que su clase de preocupación está incluida en sus clases objetivo, una línea es suficiente:

describe SomeTargetedController do
  describe ''includes MyControllerConcern'' do
    it { expect(SomeTargetedController.ancestors.include? MyControllerConcern).to eq(true) }
  end
end

Answer 2

Estoy usando una forma más simple de probar mis preocupaciones con el controlador, no estoy seguro de si esta es la manera correcta, pero parece mucho más simple que la anterior y tiene sentido para mí, es como usar el alcance de los controladores incluidos. Avíseme si hay algún problema con este método. controlador de muestra:

class MyController < V1::BaseController
  include MyConcern

  def index
    ...

    type = column_type(column_name)
    ...
  end

fin

mi preocupación del controlador:

module MyConcern
  ...
  def column_type(name)
    return :phone if (column =~ /phone/).present?
    return :id if column == ''id'' || (column =~ /_id/).present?
   :default
  end
  ...

end

prueba de especificación para su preocupación:

require ''spec_helper''

describe SearchFilter do
  let(:ac)    { V1::AppointmentsController.new }
  context ''#column_type'' do
    it ''should return :phone for phone type column'' do
      expect(ac.column_type(''phone_daytime'')).to eq(:phone)
    end

    it ''should return :id for id column'' do
      expect(ac.column_type(''company_id'')).to eq(:id)
    end

    it ''should return :id for id column'' do
      expect(ac.column_type(''id'')).to eq(:id)
    end

    it ''should return :default for other types of columns'' do
      expect(ac.column_type(''company_name'')).to eq(:default)
    end
  end
end

Answer 3

Mi respuesta puede parecer un poco más complicada que estas por @Benj y @Calin, pero tiene sus ventajas.

describe Concerns::MyConcern, type: :controller do

  described_class.tap do |mod|
    controller(ActionController::Base) { include mod }
  end

  # your tests go here
end

Antes que nada, recomiendo el uso de un controlador anónimo que es una subclase de ActionController::Base , no ApplicationController ni ningún otro controlador base definido en su aplicación. De esta forma, puede probar la preocupación de forma aislada de cualquiera de sus controladores. Si espera que se definan algunos métodos en un controlador base, simplemente resúmalos.

Además, es una buena idea evitar volver a escribir el nombre del módulo de preocupación, ya que ayuda a evitar los errores de copiar y pegar. Desafortunadamente, described_class no es accesible en un bloque pasado al controller(ActionController::Base) , entonces uso el método #tap para crear otro enlace que almacena described_class en una variable local. Esto es especialmente importante cuando se trabaja con API versionadas. En tal caso, es bastante común copiar grandes volúmenes de controladores cuando se crea una nueva versión, y entonces es terriblemente fácil cometer un error tan sutil de copiar y pegar.

Answer 4

Simplificando en el método 2 de la respuesta más votada.

Prefiero el anonymous controller admitido en rspec http://www.relishapp.com/rspec/rspec-rails/docs/controller-specs/anonymous-controller

Harás:

describe ApplicationController, type: :controller do
  controller do
    include MyControllerConcern

    def index; end
  end

  describe ''GET index'' do
    it ''will work'' do
      get :index
    end
  end
end

Tenga en cuenta que debe describir ApplicationController y establecer el tipo en caso de que esto no ocurra de manera predeterminada.