RSpec vs Cucumber (historias de RSpec) [cerrado]

Question

¿Cuándo debo usar especificaciones para la aplicación Rails y cuándo Cucumber (antiguas historias de rspec)?Sé cómo funcionan ambos y cómo uso activamente las especificaciones, por supuesto.Pero todavía se siente extraño usar pepino.Mi opinión actual sobre esto es que es conveniente usar Cucumber cuando estás implementando una aplicación para el cliente y aún no entiendes cómo se supone que funciona todo el sistema.

¿Pero qué pasa 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?

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

Answer 1

Si no lo ha hecho, es posible que desee comprobar hacia fuera el excelente artículo de Dan Norte, ¿Qué hay en una historia? 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ífico que ayuda a enfocar la articulación del propietario del producto de las funciones que desea construir. Este es el "token para una conversación" uso de historias, y sería útil si implementamos las historias de código. En segundo lugar, cuando el proceso está funcionando lo suficientemente bien que tenemos historias completas antes que comience a escribir la función (más de un ideal que nos esforzamos para que una realidad diaria), que tiene sus criterios de aceptación explicadas con claridad y usted sabe exactamente qué y cuánto a construir.

En nuestros rieles de trabajo, historias de pepino no sustituyen a las pruebas unitarias rspec. Los dos van de la mano. En la práctica, las pruebas de unidad tienden a impulsar el desarrollo de los modelos y controladores, y las historias tienden a impulsar el desarrollo de las vistas (que tienden a no escribir rspec para nuestros puntos de vista) y proporcionan una buena prueba de la aplicación en su totalidad de la la perspectiva del usuario.

Si está trabajando en solitario, el aspecto de la comunicación no puede ser tan interesante para usted, pero la prueba de integración que se obtiene de pepino podría ser. Si se toma ventaja de webrat , escribiendo pepino puede ser rápido y sin dolor para una gran parte de su funcionalidad básica.

Answer 2

Piense en ello como un ciclo:

Escriba su función pepino, a continuación, mientras que el desarrollo de las piezas para esa característica, escribir especificaciones para completar los componentes individuales. Seguir completando las especificaciones hasta que usted ha escrito una funcionalidad suficiente para la función para pasar, a continuación, escribir su siguiente función.

Answer 3

Mi opinión es que es una mala idea usar pepino en la mayoría de las situaciones, debido a los costes de la productividad su sintaxis asuma por ti. He escrito extensamente sobre el tema en ¿Por qué molestarse con Pepino pruebas?

Answer 4

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

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

Answer 5

Hoy en día se puede utilizar con rspec capibara y el selenio WebDriver y evitar tener que construir y mantener todos los programas de análisis de la historia de pepino. Esto es lo que recomendaría:

1. Escriba su historia
2. Uso RSpec, me gustaría crear un ex prueba de integración: spec / integraciones / socks_rspec.rb
3. A continuación, me gustaría crear una prueba de integración que incluye una nueva describir y bloquear para cada escenario
4. A continuación, me gustaría poner en práctica la funcionalidad mínima requiero para conseguir la prueba de integración y al mismo tiempo profundizar hacia atrás (en los controladores y modelos, etc) Me gustaría TDD en los 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

Hay que destacar, sin embargo, es que las pruebas del controlador y de integración tienen solapamiento que puede no ser necesario por lo que tiene que utilizar su mejor juicio para que no pierda su tiempo.

Además, una vez que encuentre su ranura le resultará más agradable para desarrollar el uso de BDD, hasta entonces, no se sienta culpable si usted no se siente como que está haciendo que sea perfecto y no más de pensarlo. Que va a hacer muy bien!

Answer 6

¿Pero qué pasa 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?

Todavía necesitas pepino.Lo necesita para documentar cómo ve que funciona el sistema y lo necesita para asegurarse de no haber interrumpido la funcionalidad cuando cambia cosas.

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