RSpec vs Pepino (historias de RSpec) [cerrado]

¿Cuándo debo usar las especificaciones para la aplicación Rails y cuándo Cucumber (ex rspec-stories)? Sé cómo funcionan y usan activamente las especificaciones, por supuesto. Pero todavía se siente raro usar Pepino. Mi opinión actual sobre esto es que es conveniente usar Cucumber cuando está implementando una aplicación para el cliente y aún no entiendo cómo se supone que funciona todo el sistema.

Pero, ¿y si estoy haciendo mi propio proyecto? La mayor parte del tiempo, sé cómo interactúan las partes del sistema. Todo lo que necesito hacer es escribir un montón de pruebas unitarias. ¿Cuáles son las situaciones posibles cuando necesitaría pepino entonces?

Y, como una segunda pregunta correspondiente: ¿tengo que escribir especificaciones si escribo historias de pepino? ¿No sería una doble prueba de lo mismo?

Si aún no lo ha hecho, puede consultar el excelente artículo de Dan North, ¿Qué hay en una historia? como punto de partida

Tenemos dos usos principales para las historias de pepino. Primero, debido a que la forma de la historia es muy específica, ayuda a enfocar la articulación del propietario del producto de las características que quiere construir. Este es el uso "simbólico de una conversación" de las historias, y sería valioso si implementamos o no las historias en código. En segundo lugar, cuando el proceso funciona lo suficientemente bien como para tener historias completas antes de comenzar a escribir la función (más un ideal por el que nos esforzamos que una realidad diaria), tiene sus criterios de aceptación enunciados claramente y sabe exactamente qué y cómo Mucho para construir.

En nuestro trabajo de Rails, las historias de pepino no sustituyen a las pruebas unitarias rspec. Los dos van de la mano. En la práctica, las pruebas unitarias tienden a impulsar el desarrollo de los modelos y controladores, y las historias tienden a impulsar el desarrollo de las vistas (tendemos a no escribir rspec para nuestras vistas) y proporcionan una buena prueba de la aplicación en su conjunto perspectiva del usuario.

Si trabaja solo, el aspecto de la comunicación puede no ser tan interesante para usted, pero las pruebas de integración que obtiene de Cucumber pueden serlo. Si aprovecha Webrat , escribir Cucumber puede ser rápido e indoloro para muchas de sus funciones básicas.

Piense en ello como un ciclo:

Escriba su característica de pepino, luego, mientras desarrolla las piezas para esa característica, escriba especificaciones para completar los componentes individuales. Continúe completando las especificaciones hasta que haya escrito suficiente funcionalidad para que la característica pase, luego escriba su próxima característica.

Mi opinión es que es una mala idea usar Cucumber en la mayoría de las situaciones debido a los costos en productividad que su sintaxis incurre en usted. Escribí extensamente sobre el tema en ¿Por qué molestarse con las pruebas de pepino?

Una historia de Pepino es más una descripción del problema general que su aplicación está resolviendo, en lugar de si los bits individuales de código funcionan (es decir, pruebas unitarias).

Como Abie describe, es casi una lista de requisitos que la aplicación debe cumplir, y es muy útil para la comunicación con su cliente, además de ser directamente comprobable.

Hoy en día puedes usar rspec con Capybara y Selenium Webdriver y evitar tener que construir y mantener todos los analizadores de historias de Cucumber. Esto es lo que recomendaría:

1. Escribe tu historia
2. Usando RSpec, crearía una prueba de integración ej: spec / integrations / socks_rspec.rb
3. Luego crearía una prueba de integración que incluye una nueva descripción y se bloquea para cada escenario
4. Luego, implementaría la funcionalidad mínima requerida para obtener la prueba de integración y mientras profundizaba (en controladores y modelos, etc.) TDD en controladores y modelos.
5. A medida que regresa, su prueba de integración debe pasar y puede continuar agregando pasos a la prueba de integración
6. repetir

Sin embargo, una cosa a tener en cuenta es que el controlador y las pruebas de integración tienen una superposición que puede no ser necesaria, por lo que debe usar su mejor criterio para no perder el tiempo.

Además, una vez que encuentre su ritmo, le resultará más agradable desarrollar usando BDD, hasta entonces no se sienta culpable si no siente que lo está haciendo perfecto y no lo piense demasiado. ¡Lo haras bien!

Pero, ¿y si estoy haciendo mi propio proyecto? La mayor parte del tiempo, sé cómo interactúan las partes del sistema. Todo lo que necesito hacer es escribir un montón de pruebas unitarias. ¿Cuáles son las situaciones posibles cuando necesitaría pepino entonces?

Aún necesitas pepino. Lo necesita para documentar cómo ve el funcionamiento del sistema, y ​​lo necesita para asegurarse de que no ha roto la funcionalidad cuando cambia las cosas.

En otras palabras, necesita historias de pepino por las mismas razones que necesita pruebas unitarias: solo funcionan en un nivel más alto de abstracción.