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

rspec rails tutorial

Question

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

Answer 1

El contexto es un alias para describir, y por lo tanto funcionalmente equivalente. Puede usarlos indistintamente, la única diferencia está en cómo se lee su archivo de especificación (por ejemplo, no hay diferencia en el resultado de la prueba). El libro de Rspec dice:

"Tendemos a usar describe() para cosas y context() para contexto".

Personalmente, me gusta usar describe() , pero puedo ver por qué las personas prefieren el context() .

La característica y el escenario son una parte de Capybara, y no rspec, y están destinados a ser utilizados para las pruebas de aceptación.

La característica es equivalente a describir / contexto, y escenario equivalente a ella / ejemplo.

Si está escribiendo pruebas de aceptación con Capybara, use la sintaxis de la característica / escenario, si no utiliza la sintaxis de describe / it.

Answer 2

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

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

El propósito de "describir" es envolver un conjunto de pruebas contra una funcionalidad, mientras que "contexto" es para envolver un conjunto de pruebas contra una funcionalidad bajo 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 de si esta es una regla generalmente aceptada, pero considero que este enfoque es claro y bastante fácil de entender.