RSpec: describir, contexto, característica, escenario?

describe, context, feature, scenario: ¿Cuál es la diferencia (s) entre los cuatro y cuándo utilizar cada uno?

El contextes un alias para describe, por lo que son funcionalmente equivalentes. Puede usarlos indistintamente, la única diferencia es cómo se lee su archivo de especificaciones. No hay diferencia en la salida de prueba, por ejemplo. El libro RSpec dice:

Solemos usar describe()para las cosas y context()para el contexto ”.

Personalmente me gusta usar describe, pero puedo ver por qué la gente lo prefiere context.

featurey scenarioson parte de Capybara, y no RSpec, y están destinados a ser utilizados para pruebas de aceptación. featurees equivalente a describe/ contexty scenarioequivalente a it/ example.

Si está escribiendo pruebas de aceptación con Capybara, use la sintaxis feature/ scenario, si no, use la sintaxis describe/ it.

Esta mañana, mientras escribía algunas especificaciones, tenía la misma pregunta. Por lo general, lo uso principalmente describey no pienso particularmente en esto, pero esta mañana estaba lidiando con muchos casos y diferentes especificaciones para un módulo, por lo que tenía que ser fácilmente comprensible para el próximo desarrollador que lea esas especificaciones. Así que le pregunté a Google sobre esto y encontré esto: describir vs.contexto en rspec , cuya respuesta encuentro bastante interesante:

De acuerdo con el código fuente de rspec, "contexto" es sólo un método de alias de "describir", lo que significa que no hay diferencia funcional entre estos dos métodos. Sin embargo, existe una diferencia contextual que ayudará a que sus pruebas sean más comprensibles al usar ambas.

El propósito de "describir" es ajustar un conjunto de pruebas a una funcionalidad, mientras que "contexto" es ajustar un conjunto de pruebas a una funcionalidad en el mismo estado.

Entonces, confiando en este principio, escribirías una especificación como esta:

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do
  
  # 1st state of the feature/behaviour I'm testing
  context "without a order param" do
    ...
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with a given order column" do
    ..
  end

  # Last state of the feature/behaviour I'm testing
  context "with a given order column + reverse" do
    ..
  end
end

No estoy seguro si esta es una regla generalmente aceptada, pero encuentro este enfoque claro y bastante fácil de entender.

Ampliando la excelente respuesta de Pierre , según los documentos :

La característica y el escenario DSL corresponden a describirlo y, respectivamente. Estos métodos son simplemente alias que permiten que las especificaciones de características se interpreten más como pruebas de aceptación y de clientes.

Entonces, para aquellos familiarizados con los términos Mocha y describirlo (que son más adecuados para describir el comportamiento de una prueba desde la perspectiva de un usuario, por lo tanto, Mocha funciona principalmente como un marco de prueba frontal), podría:

• optar por utilizar siempre y solamente describey itu otro emparejamiento
• elegir usar itdentro de un contextbloque que requiere que se realicen múltiples afirmaciones / pruebas en un estado específico de la aplicación

Siguiendo con la segunda opción, aún puede seguir la intención de "... ajustar [hacer ping] un conjunto de pruebas contra una funcionalidad en el mismo estado".

Por lo tanto, sus pruebas podrían verse así:

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do

  # 1st state of the feature/behaviour I'm testing
  context "without an order param" do
    # 1st and only test we want to run in this state
    it "asks the user for missing order param" do
     ...
    end
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with an invalid order param" do
    # 1st test we want to run in this state
    it "validates and rejects order param" do
      ...
    end
    # 2nd test we want to run in this state
    it "returns an error to user" do
      ...
    end
  end

  # 3rd state of the feature/behaviour I'm testing with multiple tests
  context "with a valid order param" do
    it "validates and accepts order param" do
      ...
    end
    it "displays correct price for order" do
      ...
    end
    unless being_audited
      it "secretly charges higher price to user" do
        ...
      end
    end
  end
end

De esta manera, omite la featurepalabra clave por completo, que es posible que desee utilizar para funciones específicas de la interfaz o si está haciendo FDD (desarrollo impulsado por funciones), que puede resultar incómodo para algunos. Pregunte aquí a su equipo de desarrolladores.

Advertencia: no siempre sigamos los estándares de la industria, imagínese si modelamos todas nuestras pruebas según la filosofía de Volkswagen.