¿Cuándo usar RSpec let ()?

Tiendo a usar bloques anteriores para establecer variables de instancia. Luego uso esas variables en mis ejemplos. Hace poco me encontré let(). Según los documentos de RSpec, se utiliza para

... para definir un método auxiliar memorable. El valor se almacenará en caché en varias llamadas en el mismo ejemplo, pero no en todos los ejemplos.

¿Cómo es esto diferente de usar variables de instancia en bloques anteriores? ¿Y también cuándo deberías usar let()vs before()?

Siempre prefiero letuna variable de instancia por un par de razones:

• Las variables de instancia surgen cuando existen referencias. Esto significa que si usted escribe mal la ortografía de la variable de instancia, se creará una nueva e inicializará nil, lo que puede conducir a errores sutiles y falsos positivos. Como letcrea un método, obtendrás un NameErrorerror cuando lo escribes mal, lo cual me parece preferible. También facilita la refactorización de las especificaciones.
• Se before(:each)ejecutará un enlace antes de cada ejemplo, incluso si el ejemplo no usa ninguna de las variables de instancia definidas en el enlace. Esto no suele ser un gran problema, pero si la configuración de la variable de instancia lleva mucho tiempo, está desperdiciando ciclos. Para el método definido por let, el código de inicialización solo se ejecuta si el ejemplo lo llama.
• Puede refactorizar desde una variable local en un ejemplo directamente en let sin cambiar la sintaxis de referencia en el ejemplo. Si refactoriza a una variable de instancia, debe cambiar la forma en que hace referencia al objeto en el ejemplo (por ejemplo, agregar un @).
• Esto es un poco subjetivo, pero como señaló Mike Lewis, creo que hace que la especificación sea más fácil de leer. Me gusta la organización de definir todos mis objetos dependientes lety mantener mi itbloque agradable y corto.

Puede encontrar un enlace relacionado aquí: http://www.betterspecs.org/#let

La diferencia entre usar variables de instancias y let()es que let()se evalúa de forma diferida . Esto significa que let()no se evalúa hasta que el método que define se ejecuta por primera vez.

La diferencia entre beforey letes que let()le brinda una buena manera de definir un grupo de variables en un estilo 'en cascada'. Al hacer esto, la especificación se ve un poco mejor al simplificar el código.

He reemplazado completamente todos los usos de las variables de instancia en mis pruebas rspec para usar let (). He escrito un ejemplo rápido para un amigo que lo usó para enseñar una pequeña clase de Rspec: http://ruby-lambda.blogspot.com/2011/02/agile-rspec-with-let.html

Como algunas de las otras respuestas aquí dicen, let () se evalúa de manera diferida, por lo que solo cargará las que requieren carga. SECA la especificación y la hace más legible. De hecho, he portado el código Rspec let () para usar en mis controladores, en el estilo de la joya de herencia_recursos. http://ruby-lambda.blogspot.com/2010/06/stealing-let-from-rspec.html

Junto con la evaluación diferida, la otra ventaja es que, combinado con ActiveSupport :: Concern, y la especificación / soporte / comportamiento de cargar todo, puede crear su propia mini-DSL de especificación específica para su aplicación. He escrito algunos para probar contra Rack y recursos RESTful.

La estrategia que uso es Factory-everything (a través de Machinist + Forgery / Faker). Sin embargo, es posible usarlo en combinación con los bloques before (: each) para precargar las fábricas para un conjunto completo de grupos de ejemplo, lo que permite que las especificaciones se ejecuten más rápido: http://makandra.com/notes/770-taking-advantage -de-rspec-s-let-in-before-blocks

Es importante tener en cuenta que let es un vago evaluado y no incluye métodos de efectos secundarios; de lo contrario, no podrá cambiar fácilmente de let a before (: each) . Puedes usar let! en lugar de dejar que se evalúe antes de cada escenario.

En general, let()es una sintaxis más agradable y te ahorra escribir @namesímbolos por todas partes. Pero, advertencia emptor! Descubrí que let()también introduce errores sutiles (o al menos rascarse la cabeza) porque la variable realmente no existe hasta que intentas usarla ... Muestra el signo de cuento: si agregas un putsdespués let()para ver que la variable es correcta, permite una especificación para aprobar, pero sin la putsespecificación falla: ha encontrado esta sutileza.

¡También he descubierto que let()no parece estar en caché en todas las circunstancias! Lo escribí en mi blog: http://technicaldebt.com/?p=1242

¿Tal vez sea sólo yo?

let es funcional ya que es esencialmente un Proc. También está en caché.

Un problema que encontré de inmediato con let ... En un bloque Spec que está evaluando un cambio.

let(:object) {FactoryGirl.create :object}

expect {
  post :destroy, id: review.id
}.to change(Object, :count).by(-1)

Deberá asegurarse de llamar letfuera de su bloque esperado. es decir, está llamando FactoryGirl.createen su bloque let. Normalmente hago esto verificando que el objeto persiste.

object.persisted?.should eq true

De lo contrario, cuando letse llama al bloque por primera vez, se producirá un cambio en la base de datos debido a la instanciación diferida.

Actualizar

Solo agrego una nota. Tenga cuidado jugando código golf o en este caso rspec golf con esta respuesta.

En este caso, solo tengo que llamar a algún método al que responda el objeto. Entonces invoco el _.persisted?método _ en el objeto como verdadero. Todo lo que intento hacer es crear una instancia del objeto. ¿Podrías llamar vacío? o nulo? también. El punto no es la prueba, sino traer el objeto a la vida llamándolo.

Entonces no puedes refactorizar

object.persisted?.should eq true

ser - estar

object.should be_persisted 

como el objeto no ha sido instanciado ... es vago. :)

Actualización 2

aprovechar el let! sintaxis para la creación instantánea de objetos, lo que debería evitar este problema por completo. Tenga en cuenta, sin embargo, que derrotará mucho el propósito de la pereza del let no golpeado.

También, en algunos casos, es posible que desee aprovechar la sintaxis del tema en lugar de permitir, ya que puede ofrecerle opciones adicionales.

subject(:object) {FactoryGirl.create :object}

Nota para Joseph: si está creando objetos de base de datos en una before(:all), no se capturarán en una transacción y es mucho más probable que se quede en la base de datos de prueba. Usar en su before(:each)lugar.

La otra razón para usar let y su evaluación perezosa es para que pueda tomar un objeto complicado y probar piezas individuales anulando let en contextos, como en este ejemplo muy artificial:

context "foo" do
  let(:params) do
     { :foo => foo,  :bar => "bar" }
  end
  let(:foo) { "foo" }
  it "is set to foo" do
    params[:foo].should eq("foo")
  end
  context "when foo is bar" do
    let(:foo) { "bar" }
    # NOTE we didn't have to redefine params entirely!
    it "is set to bar" do
      params[:foo].should eq("bar")
    end
  end
end

"antes" por defecto implica before(:each). Ref. The Rspec Book, copyright 2010, página 228.

before(scope = :each, options={}, &block)

Utilizo before(:each)para sembrar algunos datos para cada grupo de ejemplo sin tener que llamar al letmétodo para crear los datos en el bloque "it". Menos código en el bloque "it" en este caso.

Lo uso letsi quiero algunos datos en algunos ejemplos pero no en otros.

Tanto antes como let son excelentes para SECAR los bloques "it".

Para evitar confusiones, "let" no es lo mismo que before(:all). "Let" reevalúa su método y valor para cada ejemplo ("it"), pero almacena en caché el valor en varias llamadas en el mismo ejemplo. Puede leer más sobre esto aquí: https://www.relishapp.com/rspec/rspec-core/v/2-6/docs/helper-methods/let-and-let

Voz disidente aquí: después de 5 años de rspec no me gusta letmucho.

1. La evaluación perezosa a menudo confunde la configuración de la prueba

Se vuelve difícil razonar sobre la configuración cuando algunas cosas que se han declarado en la configuración no están afectando el estado, mientras que otras sí.

Con el tiempo, debido a la frustración alguien cambia leta let!(lo mismo sin evaluación perezosa) con el fin de conseguir su trabajo de especificaciones. Si esto funciona para ellos, nace un nuevo hábito: cuando se agrega una nueva especificación a una suite anterior y no funciona, lo primero que intenta el escritor es agregar explosiones a las letllamadas aleatorias .

Muy pronto, todos los beneficios de rendimiento se han ido.

2. La sintaxis especial es inusual para usuarios que no son rspec

Prefiero enseñar Ruby a mi equipo que los trucos de rspec. Las variables de instancia o las llamadas a métodos son útiles en todas partes en este proyecto y en otros, la letsintaxis solo será útil en rspec.

3. Los "beneficios" nos permiten ignorar fácilmente los buenos cambios de diseño

let()es bueno para las dependencias costosas que no queremos crear una y otra vez. También se combina bien subject, lo que le permite secar llamadas repetidas a métodos de múltiples argumentos

Las dependencias costosas se repiten en muchas ocasiones, y los métodos con grandes firmas son puntos en los que podríamos mejorar el código:

• tal vez pueda introducir una nueva abstracción que aísle una dependencia del resto de mi código (lo que significaría que menos pruebas lo necesitan)
• tal vez el código bajo prueba está haciendo demasiado
• tal vez necesito inyectar objetos más inteligentes en lugar de una larga lista de primitivas
• tal vez tengo una violación de decir-no-preguntar
• tal vez el costoso código se puede hacer más rápido (más raro, tenga cuidado con la optimización prematura aquí)

En todos estos casos, puedo abordar el síntoma de las pruebas difíciles con un bálsamo calmante de magia rspec, o puedo tratar de abordar la causa. Siento que pasé demasiado de los últimos años en el primero y ahora quiero un código mejor.

Para responder a la pregunta original: preferiría no hacerlo, pero todavía lo uso let. Lo uso principalmente para encajar con el estilo del resto del equipo (parece que la mayoría de los programadores de Rails en el mundo ahora están inmersos en su magia rspec, por lo que es muy frecuente). A veces lo uso cuando agrego una prueba a algún código del que no tengo control, o no tengo tiempo para refactorizar a una mejor abstracción: es decir, cuando la única opción es el analgésico.

Utilizo letpara probar mis respuestas HTTP 404 en mis especificaciones API usando contextos.

Para crear el recurso, yo uso let!. Pero para almacenar el identificador de recursos, yo uso let. Echa un vistazo a cómo se ve:

let!(:country)   { create(:country) }
let(:country_id) { country.id }
before           { get "api/countries/#{country_id}" }

it 'responds with HTTP 200' { should respond_with(200) }

context 'when the country does not exist' do
  let(:country_id) { -1 }
  it 'responds with HTTP 404' { should respond_with(404) }
end

Eso mantiene las especificaciones limpias y legibles.