ruby-on-rails - palabra - quienes o quiénes ortografía
Historias y especificaciones de RSpec: ¿Cuándo usar qué? (4)
Así que quiero comenzar a usar historias de RSpec, pero no estoy seguro de dónde encajan las especificaciones de controlador de escritura, modelo y vista.
Por ejemplo, tiene la historia "Iniciando sesión" con el escenario "El usuario proporciona una contraseña incorrecta", no termina probando las mismas cosas que las especificaciones del controlador / modelo (la respuesta debe mostrar ..., el usuario. Debe estar, etc. .)
Entonces mi pregunta es: para aquellos que están acostumbrados a hacer bdd (o dd de historia) 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")?
Creo 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 contenga "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.
Según lo veo, las especificaciones de vista, controlador y modelo son solo 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 publico 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 que un flujo de trabajo útil es:
- escribir un escenario de historia que describa la funcionalidad que necesito agregar.
- tan pronto como sea posible, escriba los pasos para esa historia, para que pueda ejecutarla (incluso si todos los pasos fallan).
- escriba una especificación para algo que necesita esa historia (el modelo puede ser un buen lugar para comenzar).
- escriba el código para hacer que pase la especificación.
- escriba más especificaciones y código hasta que pase la historia.
De esa manera, la historia puede guiarlo en lo que sus especificaciones deben probar.
Editar : este es un buen artículo que toca la relación entre historias y especificaciones.
Si está comenzando con historias ahora (en lugar de tener muchas historias heredadas) es posible que desee ver Pepino, que es el reemplazo a largo plazo para el corredor de historias RSpec.
La forma más sencilla 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 forma de hacer BDD "fuera de dentro" es comenzar con historias basadas en los requisitos del cliente y luego agregar especificaciones para los componentes que usted necesita cuando implementa 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.
Pat Maddox (equipo básico de RSpec) cree que bajo ciertas suposiciones, puede omitir las especificaciones del controlador cuando use las características / características de Pepino
Lea sobre su punto de vista aquí
¿Qué tal si omites la especificación de vista si tienes Cucumber + Capybara en ella? Tiendo a encontrar ver especificaciones no necesarias.