Historias y especificaciones de RSpec: ¿Cuándo usar qué?

Question

Así que quiero comenzar a usar historias de RSpec, pero no estoy seguro de dónde caben las especificaciones de controlador, modelo y vista de escritura.

Por ejemplo, tiene la historia "Iniciando sesión" con el "Usuario proporciona una contraseña incorrecta" escenario , no terminas probando las mismas cosas que las especificaciones del controlador/modelo (response.should render ..., user.should be_nil, etc.)

Así que mi pregunta es: para aquellos que están acostumbrados a hacer bdd (o historia dd) con RoR, ¿todavía escribes especificaciones de modelo/controlador? Si es así, ¿cómo es el flujo de trabajo que sigues ("primera historia, luego estrecha a especificaciones específicas")?

Answer 1

Si está comenzando con historias ahora (en lugar de tener muchas historias heredadas), puede consultar Cucumber, que es el reemplazo a largo plazo del corredor de historias RSpec.

La forma más fácil de dividir entre especificaciones e historias es utilizar historias para pruebas de pila completa de requisitos comerciales y especificaciones para especificaciones aisladas de bajo nivel de los componentes (vistas, ayudantes, controladores y modelos). 'Full stack' puede variar desde controlador/modelo/base de datos a través de simulación de cliente con Webrat hasta pruebas en el navegador con Watir o Selenium.

La mejor manera de hacer BDD "fuera de dentro" es comenzar con historias basadas en los requisitos del cliente y luego agregar las especificaciones para los componentes que necesita al implementar las historias. Lo ideal es que cubra por completo los componentes individuales con especificaciones y tenga historias para los flujos de trabajo más importantes de sus usuarios, de modo que pueda verificar al más alto nivel que su aplicación ofrece la funcionalidad que le han pedido.

Answer 2

Me parece que las historias son útiles cuando prueban el comportamiento que el usuario realmente realiza u observa, por lo que en lugar de probar que se procesó la plantilla de "inicio de sesión fallido", compruebe que la respuesta "no se pudo iniciar sesión". En mi humilde opinión, es mejor que las historias nunca se refieran a modelos, vistas o controladores directamente, aunque a veces es difícil hacer que los pasos funcionen sin crear instancias de modelo manualmente.

Como yo lo veo, las especificaciones de vista, controlador y modelo son solo una parte de la imagen. Hablan el idioma de la implementación ("la acción del controlador X debe hacer Y para el modelo Z") y prueba que las partes individuales de su aplicación hacen lo correcto. Las historias completan la imagen hablando el idioma del usuario ("cuando publique un comentario, debería ver el comentario que publiqué") y probando que las piezas se ajustan de manera que satisfagan los criterios de aceptación del cliente.

encuentro un flujo de trabajo útil es:

• escribir un escenario historia que describe la funcionalidad tengo que añadir.
• tan pronto como sea posible, escriba los pasos para esa historia, para que pueda ejecutarla (incluso si fallan todos los pasos).
• escribe una especificación para algo necesario para esa historia (el modelo puede ser un buen lugar para comenzar).
• escribe el código para hacer que pase la especificación.
• escribe más especificaciones y código hasta que pase la historia.

De esta manera la historia puede guiarlo en lo que sus especificaciones deben probar.

Editar: this es un buen artículo que trata sobre la relación entre historias y especificaciones.

Answer 3

Pat Maddox (equipo central RSpec) piensa que, en algunos supuestos, puede saltarse las especificaciones del controlador cuando se utiliza historias de pepino/cuenta

Lea sobre su punto de vista here

Answer 4

¿Qué hay de saltarse las especificaciones vista si Tiene Cucumber + Capybara en él. Tiendo a encontrar ver especificaciones no necesarias.