ruby-on-rails - rack_test - ruby capybara github

Rspec y organización de grandes archivos de especificaciones.

Question

Me preguntaba cómo otros organizan archivos de especificaciones grandes (especialmente para modelos) con muchos contextos y secciones organizadas en bloques de descripción para validaciones y otras especificaciones que se pueden agrupar de alguna manera significativa.

¿Mantienen todas las especificaciones relativas a un modelo en el mismo archivo de especificaciones para ese modelo, o se dividen en módulos de una forma u otra?

Nunca me he preocupado demasiado por esto hasta ahora, pero me pregunto qué hacen los demás, ya que no parece haber algún tipo de acuerdo en torno a una mejor práctica o algo así.

Tengo algunos archivos de especificaciones bastante grandes para algunos modelos que me gustaría organizar en archivos más pequeños, y hay poca o ninguna funcionalidad compartida entre los diferentes modelos, así que no estoy seguro de si los ejemplos compartidos serían la forma de hacerlo. (independientemente de la reutilización) o si hay alguna mejor manera. ¿Alguna sugerencia?

Gracias por adelantado.

Answer 1

Los contextos anidados pueden ayudarlo aquí, pero manténgalos poco profundos (por lo general, un nivel profundo). Hay dos variables a considerar en cada ejemplo: givens (estado de inicio) y qué método se está invocando. Puedes agrupar cosas por método o estado:

# by method
describe Stack do
  describe "#push" do
    it "adds an element to an empty stack"
    it "adds an element to a non-empty stack"
  end

  describe "#pop" do
    it "returns nil from an empty stack"
    it "returns the last element of a non-empty stack"
    it "removes the last element from a non-empty stack"
  end
end

# by state
describe Stack do
  context "when empty" do
    specify "push adds an element"
    specify "pop returns nil"
  end

  context "when not empty" do
    specify "push adds an element"
    specify "pop returns last element"
    specify "pop removes last element"
  end
end

He usado ambos enfoques y he visto que ambos funcionan realmente bien y muy mal. La clave de ambos enfoques es que los ejemplos cuentan una historia mientras lees de arriba a abajo. A medida que los requisitos evolucionan, esto significa que necesita revisar este archivo, al igual que lo hace con su código de implementación. Una forma fácil de verificar que la especificación tiene sentido es ejecutarlo con el formateador de documentación:

rspec stack_spec.rb --format documentation

Esto escupe todos los nombres en orden (siempre que no esté usando --order rand):

Stack
  #push
    adds an element to an empty stack
    adds an element to a non-empty stack
  #pop
    returns nil from an empty stack
    returns the last element of a non-empty stack
    removes the last element from a non-empty stack

o

Stack
  when empty
    push adds an element
    pop returns nil
  when not empty
    push adds an element
    pop returns last element
    pop removes last element

Una vez que vea esta salida, le resultará bastante claro si la organización que está utilizando tiene sentido o no.