RSpec vs Cucumber (historias RSpec)

Question

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

¿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 posibles situaciones en las que 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 la misma cosa?

Answer 1

Si no lo ha hecho aún, puede consultar el excelente artículo de Dan North, What's in a Story? como punto de partida.

Tenemos dos usos principales para las historias de pepino. En primer lugar, debido a que la forma de la historia es muy específica, ayuda a enfocar la articulación del dueño del producto de las características que quiere construir. Este es el uso de historias de "token para una conversación", y sería valioso si implementamos las historias en código o no. Segundo, cuando el proceso está funcionando lo suficientemente bien como para tener historias completas antes de comenzamos a escribir la característica (más de un ideal que buscamos que una realidad diaria), usted tiene sus criterios de aceptación explicados claramente y usted sabe exactamente qué y cuánto construir

En nuestro trabajo Rails, las historias de pepino no sustituyen a las pruebas unitarias de 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 nuestros puntos de vista) y proporcionan una buena prueba de la aplicación como un todo desde el la perspectiva del usuario

Si trabajas solo, el aspecto de comunicación puede no ser tan interesante para ti, pero las pruebas de integración que obtienes de Cucumber pueden ser. Si toma ventaja de webrat, escribir Cucumber puede ser rápido y sencillo para gran parte de su funcionalidad básica.

Answer 2

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

Como describe Abie, 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.

Answer 3

pensar en él como un ciclo:

Escribir característica de pepino, a continuación, mientras que el desarrollo de las piezas para esa característica, escribir 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 función.

Answer 4

¿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 posibles situaciones en las que necesitaría Pepino entonces?

Aún necesita Pepino. Lo necesita para documentar cómo ve que el sistema funciona, y lo necesita para asegurarse de que no haya roto la funcionalidad cuando cambie las cosas.

En otras palabras, necesitas historias de Pepino por las mismas razones que necesitas pruebas unitarias, solo trabajan en un nivel más alto de abstracción.

Answer 5

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

1. escribir su historia
2. Usando RSpec, me gustaría crear un ex prueba de integración: SPEC/integraciones/socks_rspec.rb
3. Entonces me gustaría crear una prueba de integración, que incluye una nueva descripción y bloque para cada escenario
4. Luego implementaría la funcionalidad mínima requerida para obtener la prueba de integración y, mientras más atrás (en controladores y modelos, etc.), TDD en controladores y modelos.
5. A medida que entran una copia de seguridad de prueba de integración debe pasar y se puede seguir añadiendo pasos para la prueba de integración
6. repetición

Una cosa a destacar, sin embargo, es que las pruebas del controlador y de integración tienen solapamiento eso puede no ser necesario, 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!

Answer 6

Mi opinión es que es una mala idea usar Pepino en la mayoría de las situaciones debido a los costos en la productividad que su sintaxis genera. Escribí extensamente sobre el tema en Why Bother With Cucumber Tests?