allow - rspec mock ruby

En RSpec, ¿hay un método equivalente a "unstub" pero para "should_receive"?

Question

¿Hay algún método para eliminar cualquier trozo y burla mientras se usa RSpec?

Ejemplo:

RestClient.should_receive(:delete).with("http://www.example.com")
...
... 

# this will remove the mocking of "should_receive" and 
# restore the proper "delete" method on "RestClient".
RestClient.mocking_reset

( mocking_reset es mi nombre ficticio para la funcionalidad requerida).

Sé que existe el método "unstub" que restablece "stubs" pero no "should_receive".

Entonces, ¿hay algún método equivalente a "unstub" pero para "should_receive"?

Panayotis

Answer 1

Para RSpec> = 2.14, la respuesta aceptada ya no funcionará. Te remito a la respuesta de Bernhard Köhler en este hilo (reproducida a continuación para proteger contra la rotura del enlace): método indefinido `rspec_reset ''con la versión rspec 2.14

El método de reinicio no existe en RSpec 2.14. En cambio, es un método de ayuda definido dentro del archivo spec_helper.rb para el proyecto rspec-mocks.

module VerifyAndResetHelpers
  def verify(object)
    RSpec::Mocks.proxy_for(object).verify
  end

  def reset(object)
    RSpec::Mocks.proxy_for(object).reset
  end
end

Puede ver que este método delega la acción de reinicio en el proxy subyacente en lugar de virar en la definición de clase del objeto en cuestión.

Answer 2

Por el momento (rspec-mocks 2.10.1) no hay un método equivalente a unstub pero para should_receive . Puede restablecer todos los rspec_reset y burlas con rspec_reset , y también puede escribir hacks sucios para eliminar una expectativa particular (que no recomendaría).

El siguiente es un ejemplo de eliminación de todos los resguardos y expectativas en un objeto:

describe "resetting stubs and expectations with rspec_reset" do
  before do
    @person = mock(''person'')
    @person.should_receive(:poke)
  end

  it "should not fail when we reset all stubs and expectations" do
    @person.rspec_reset
  end
end

Tenga en cuenta que este método está anotado en el código fuente de @private como @private , lo que significa que debe evitar usarlo más de lo absolutamente necesario y puede romperse en versiones futuras de rspec sin previo aviso. Sin embargo, es ampliamente utilizado en las especificaciones de rspec en sí, por lo que parece menos probable que esto se desaproveche pronto.

Después de profundizar un poco más en el código de rspec-mocks, puedes, por supuesto, hacer algo realmente desagradable y deshacerte de la única expectativa específica:

# Works in rspec 2.10.1
describe "removing an expectation with an ugly hack" do
  before do
    @person = mock(''person'')
    @person.should_receive(:poke)
  end

  it "should not fail after we hack rspec by violating every law of good programming, ever" do
    @person.instance_variable_get(:@mock_proxy).instance_variable_get(:@method_double)[:poke].clear
  end
end

Esto es realmente malo ya que viola la encapsulación del paquete de prueba rspec y no debería hacerlo. En cambio, si realmente tiene una razón convincente para eliminar una expectativa particular, lo correcto sería agregar un método público en sentido ascendente en rspec-mocks que agregue un método paralelo para unstub pero para eliminar expectativas específicas. Probablemente se encuentre aquí (tenga en cuenta la definición de stub y unstub también en este archivo):

https://github.com/rspec/rspec-mocks/blob/master/lib/rspec/mocks/methods.rb

Antes de salir y utilizar cualquiera de las sugerencias anteriores para eliminar la expectativa, es posible que desee considerar si sus especificaciones realmente necesitan hacer esto o si deberían ser refactorizadas. El uso de should_receive es una afirmación sobre su código, y generalmente debería intentar crear ejemplos (es decir it bloques) que solo afirman una cosa. Me gustaría saber por qué necesita algo como rspec_reset menos que intente hacer demasiado en la configuración global (por ejemplo, before :each o antes: todos los bloques), o si sus ejemplos intentan hacer demasiado (es decir, . con múltiples aserciones en un solo ejemplo).

La única excepción a esto puede estar, por supuesto, en el conjunto de pruebas de rspec-mocks, donde rspec_reset se usa para restablecer el estado entre ejemplos que prueban la funcionalidad de la aplicación de stubs y mocks. A menos que esté haciendo eso, es probable que sus pruebas se puedan mejorar para no depender de reinicios globales de trozos y burlas en un objeto.

Espero que esto ayude y, por favor, avíseme si cree que existe un caso legítimo para agregar un método equivalente a unstub pero para expectativas de mensajes (es decir, después de usar should_receive ). Si estoy convencido de que esto está bien, consideraría agregar este método y proponerlo para ser agregado en sentido ascendente. ¿Tal vez se llamaría unset_expectation ? También siéntase libre de usar la guía en el código y las estructuras internas anteriores para armar una solicitud de extracción de rspec-mocks por su cuenta, y veremos si se acepta para crear una burla equivalente a unstub .

Answer 3

Puedes sobreescribir alguna burla previa de la siguiente manera:

expect(RestClient).to receive(:delete).and_call_original

O si no fue ningún tipo de expectativa, solo un simple trozo:

allow(RestClient).to receive(:delete).and_call_original

Recuerde que existe también expect_any_instance_of y allow_any_instance_of .