¿Elimina el pepino la necesidad de escribir pruebas unitarias?

Question

Estoy un poco confundido por la gran cantidad de marcos de prueba disponibles para Ruby/ROR.

he visto recientemente el Cucumber Railscasts y los encontró muy interesante. Entonces comencé a tener una obra de teatro y luego tuve problemas para ver conceptualmente dónde pondría varias pruebas.

Parece ser posible hacer todo lo que se puede hacer en pruebas unitarias dentro de Cucumber, así que tengo que escribir pruebas unitarias o simplemente escribir las definiciones de funciones y concentrarme en proporcionar una cobertura tan buena como puede usar eso.

¿Debo crear mis pruebas unitarias utilizando Rspec o prueba: Unidad? Cuando estoy probando la funcionalidad de Ajax, ¿debo usar Selenium o Watir?

Parece que hay tantas opciones aquí estoy luchando para ver qué herramientas utilizar y dónde están los límites.

¿Qué otras experiencias de los pueblos de pepino y dónde trazar la línea entre las pruebas de escritura pepino integración y pruebas: Unidad y/o unidad basada Rspec y pruebas funcionales. ¿Alguien está al tanto de una buena reseña sobre este tema que sugiere dónde trazar líneas entre los métodos de prueba y las fortalezas y debilidades de las diversas herramientas.

Soy consciente de que algo de esto es enfoques subjetivos pero comunes sobre la manera de atacar este problema sería bien recibido.

Answer 1

Uso pepino en un nivel alto para describir lo que un usuario debe ser capaz de ver y hacer. Use RSpec, Test: Unit, Shoulda, etc. para escribir pruebas unitarias. Directamente desde the horse's mouth:

Cuando usted decide que quiere añadir una nueva característica o corregir un error, empezar por escribir una nueva característica o escenario que describe cómo la característica debería funcionar. No escriba ningún código (todavía).

...

Esto es cuando comienza a escribir el código. Comience por escribir un par de líneas de código para abordar la falla que recibió de Cucumber. Ejecuta el pepino de nuevo. Repita y enjuague hasta que esté satisfecho con su función. Cuando llegue a los detalles esenciales, despliegue un nivel de abstracción y use RSpec, o cualquier marco de prueba de Ruby, para escribir algunas especificaciones/pruebas para sus clases.

El pepino está hecho para probar toda su pila, en conjunto, en lugar de 'unidades'.

es necesario decidir dónde trazar la línea, pero una gran cantidad de cosas bajo el capó probablemente no estaría cubierto en una prueba de pepino. Diga al registrarse, llene un formulario, con mi nombre, correo electrónico, número de teléfono, etc. Una prueba de unidad podría verificar para ver que un nuevo User también creará un nuevo TelephoneNumber. Desde la perspectiva del usuario, realmente no les importa si crea un nuevo TelephoneNumber; les preocupa que una vez que se hayan registrado, tengan una cuenta y puedan ver su número de teléfono.

No tengo también mucha experiencia escribiendo pruebas de pepino (aún no), pero espero que esto ayude un poco.

Answer 2

Personalmente no creo que usted debe dejar de escribir pruebas unitarias. Como herramienta de prueba de aceptación, Cucumber debe reemplazar tus pruebas funcionales y, si estás escribiendo, ver las pruebas.

Las características del pepino se supone que son simples y se acoplan al valor real del usuario que tiene una característica determinada.

Answer 3

Cuando una prueba de unidad falla (me refiero a una prueba de unidad real que prueba un método de forma aislada usando simulaciones), le dice qué "unidad" tiene un problema. Cuando falla una prueba de aceptación, le dice qué "característica" tiene un problema, no dónde se encuentra el problema.

Answer 4

Cuando creas una aplicación de rieles, obtienes pruebas funcionales, de interacción y de unidades por defecto. El pepino es una prueba adicional, es una manera de probar también la experiencia que tendrá su usuario. Cuando hacen clic en el botón "ir", deben ver "éxito" en lugar de 404. Esto asegurará que nada de lo que hagas accidentalmente arruine la experiencia del usuario, y que de arriba hacia abajo tu aplicación funciona para la más común casos de uso que puedas pensar Las otras pruebas están destinadas a asegurar que nada vaya mal, y que haya inspeccionado cada modelo y método con un microscopio. Es posible replicar las pruebas unitarias en su totalidad con pepino, pero sería doloroso (y muy lento de ejecutar, especialmente si está usando selenio). El mejor momento para escribir pruebas es cuando está desarrollando código, y la forma más rápida y sencilla de hacerlo es mediante el uso de las pruebas integradas de rieles y tal vez alguna ayuda adicional como shoulda, rspec, también soy un gran fan de factory-girl. Si aún no lo has probado, www.railscasts.com tiene una gran introducción a pepino, y rspec, y chica de fábrica, ... Sé que esta pregunta ya ha sido respondida (no es) pero este es mi granito de arena . Buena suerte codificando !!

Answer 5

He pensado/luchado mucho con esta pregunta, y aquí es donde he llegado.

Pepino primero y Pepino último. Cucumber proporcionará la cobertura de prueba primaria.

Los métodos de modelo básico que hacen el trabajo real de la aplicación también se deben desarrollar/cubrir con pruebas rspec/unit.

¿Por qué la unidad también prueba?

1) Las pruebas unitarias se ejecutarán mucho más rápido. 2) Esta lógica comercial central puede (probablemente) ser utilizada de varias maneras más allá de las vistas actuales (a través de las cuales Cucumber se prueba). Estos métodos deben ser martillados con todo tipo de entradas y salidas posibles llamando directamente al método en la prueba.

¿Por qué no probar el resto de los modelos, los controladores y las vistas?

1) El pepino ya lo tiene cubierto una vez. 2) Encuentro que los métodos views-controller-some-model-all trabajan juntos para hacer las cosas (piense en todo lo que hace para iniciar sesión); entonces me gusta probarlos juntos.

Answer 6

Desde mi experiencia, Cucumber y Rspec tienen un atractivo diferente. Rspec me atrae desde la perspectiva de un desarrollador porque es fácil de escribir y proporciona comentarios muy rápidos cuando algo se rompe. Cucumber no me atrae como desarrollador porque no funciona tan rápido como Rspec. Sin embargo, Cucumber sí me atrae como una parte interesada de las empresas, ya que proporciona una cobertura completa de todas las funciones.

Hazte un favor y no dejes de escribir pruebas unitarias.

Answer 7

He estado practicando Cucumber/RSpec durante el último medio año o así haciendo BDD.

En primer lugar, BDD no es fácil de conseguir, al principio se sentirá antinatural.

Pero una vez que te adentras en él, no hay otra manera de hacer programación.

Para responder a su pregunta. Para probar Javascript, necesitará un controlador de JavaScript que pueda ser utilizado por Capybara, que es utilizado por Cucumber.

capibara-webkit es lo que usan todos los niños frescos ahora en estos días

Hay una cosa importante tener en cuenta.

Las pruebas de integración son lentas.

Y las pruebas unitarias son rápidas, pero pueden ser lentas, por lo que es importante que utilice el limpiador de base de datos correcto y que escriba buenas pruebas que tengan un buen aislamiento.

Mi configuración de prueba que estoy muy contento con:

Guardia para la carga spork Spork para las pruebas rápidas pepino para las pruebas de integración capibara-webkit para Javascript a prueba RSpec para las pruebas unitarias

I No vea las pruebas y las pruebas del controlador ya que son redundantes en mi opinión, ya que un buen conocimiento de XPATH le permitirá escribir pruebas notables que incluso cubran el diseño y la estructura de su página.