Cuando se prueba con rspec, ¿dónde poner "métodos de utilidad de prueba" comunes?

Question

Supongamos que tiene un sitio de compras que vende widgets. Sin embargo, el inventario de cada widget es limitado, por lo que es importante mantener el número "widget.number_still_available" actualizado.

me gustaría escribir una prueba rspec lo largo de las líneas de

it "always displays the correct number still available" do 

    # Assume there is a before method that sets up a widget with 5 available 

    widget.number_still_available.should == 5 

    # User "a@b.com" purchases 2 widgets 
    widget.number_still_available.should == 3 

    # User "c@d.com" purchases 1 widget 
    widget.number_still_available.shhould == 2 

    # User "a@b.com" cancels purchase of 1 widget 
    widget.number_still_available.should == 4 
end 

que me gustaría ser capaz de escribir-sólo métodos de prueba que realiza la "compra" y "Cancelar" métodos. Estas acciones no corresponden a ningún método "real" en mis modelos por una variedad de razones (lo más significativo es que hay un sistema de backend desacoplado en PHP que realiza parte de las acciones de compra y cancelación).

¿Dónde está el lugar correcto para poner este código cuando se usa RSpec? En pepino, podría escribir un par de pasos, pero no estoy seguro de cuál es el equivalente correcto para RSpec.

Answer 1

Yo sugeriría hacer un nuevo archivo en spec/support llamada purchase_helpers.rb y poner este contenido en ella:

module PurchaseHelpers 
    def purchase_widgets(user, count=1) 
    # Code goes here 
    end 

    def cancel_purchase(user, count=1) 
    # Code goes here 
    end 
end 

RSpec.configure do |c| 
    c.include PurchaseHelpers 
end 

La ventaja de hacer esto en lugar de sujeción en spec/spec_helper.rb es que no está desplazando hasta ese archivo con una gran cantidad de código RSpec no relacionado con la configuración de. Separar las cosas es la mejor manera de hacer las cosas.

Answer 2

Puede soltar un monopatch en spec_helper.rb, o directamente en la parte superior del archivo de especificaciones si solo se utiliza para ese archivo.

Sería más claro y seguro hacer métodos auxiliares que usen métodos de clase existentes, en lugar de monoparquear las clases.