ruby-on-rails - rack_test - ruby capybara github

BDD con Cucumber y rspec: ¿cuándo es esto redundante?

Question

Una versión específica de Rails / tool de: ¿Cuán profundas son las pruebas de su unidad?

En este momento, actualmente escribo:

• Funciones de pepino (pruebas de integración): estas pruebas contra el HTML / JS que devuelve nuestra aplicación, pero a veces también prueban otras cosas, como llamadas a servicios de terceros.
• Pruebas de controlador RSpec (pruebas funcionales), originalmente solo si los controladores tienen alguna lógica significativa, pero ahora más y más.
• Pruebas del modelo RSpec (pruebas unitarias)

A veces esto es completamente necesario; es necesario probar el comportamiento en el modelo que no es completamente obvio ni visible para el usuario final. Cuando los modelos son complejos, definitivamente deben probarse. Pero otras veces, me parece que las pruebas son redundantes. Por ejemplo, ¿prueba el método foo si solo lo llama la bar y se prueba la bar ? ¿Qué pasa si la bar es un método de ayuda simple en un modelo que es utilizado y fácilmente comprobable en una función de pepino? ¿Probas el método en rspec y en Cucumber? Me resulta difícil lidiar con esto, ya que escribir más pruebas lleva tiempo y mantener múltiples "versiones" de lo que efectivamente son los mismos comportamientos, lo que hace que el mantenimiento del conjunto de pruebas requiera más tiempo, lo que a su vez encarece los cambios.

En resumen, ¿cree que hay un momento en que escribir solo las características de Cucumber es suficiente? ¿O debería probar siempre en todos los niveles? Si cree que hay un área gris, ¿cuál es su umbral para "esto necesita una prueba funcional / unidad"? En términos prácticos, ¿qué haces actualmente y por qué (o por qué no) crees que es suficiente?

EDITAR : Aquí hay un ejemplo de lo que podría ser "prueba excesiva". Es cierto que pude escribir esto bastante rápido, pero fue completamente hipotético.

Answer 1

Buena pregunta, una con la que he lidiado recientemente mientras trabajaba en una aplicación de Rails, también usando Cucumber / RSpec. Intento probar tanto como sea posible en todos los niveles, sin embargo, también he descubierto que a medida que crece la base de código, a veces siento que me repito innecesariamente.

Utilizando la prueba "Outside-in", mi proceso suele ser algo así como: Escenario de pepino -> Especificación de controlador -> Especificación del modelo. Cada vez me encuentro más omitiendo las especificaciones del controlador ya que los escenarios de pepino cubren gran parte de su funcionalidad. Normalmente vuelvo y agrego las especificaciones del controlador, pero puede parecer un poco pesado.

Un paso que tomo regularmente es ejecutar rcov en mis características de pepino con rake cucumber:rcov y buscar brechas notables en la cobertura. Estas son áreas del código en las que me aseguro de centrarme para que tengan una cobertura decente, ya sea de unidades o de integración.

Creo que los modelos / libs deberían probarse en unidades de forma exhaustiva, desde el primer momento, ya que es la lógica empresarial principal. Necesita trabajar en forma aislada, fuera del proceso de solicitud / respuesta web normal. Por ejemplo, si estoy interactuando con mi aplicación a través de la consola de Rails, estoy trabajando directamente con la lógica de negocios y quiero la seguridad de que los métodos que invoco en mis modelos / clases están bien probados.

Al final del día, cada aplicación es diferente y creo que depende del desarrollador (s) determinar cuánta cobertura de prueba se debe dedicar a diferentes partes de la base de código y encontrar el equilibrio adecuado para que su suite de prueba no empantanar a medida que crece su aplicación.

Aquí hay un artículo interesante que saqué de mis marcadores que vale la pena leer: http://webmozarts.com/2010/03/15/why-not-to-want-100-code-coverage/

Answer 2

El propósito de Cucumber no es ejecutar pruebas de integración. Cucumber, en general BDD, funciona como una plataforma de comunicación, una forma de mejorar la "conversación" dentro de un gran equipo de desarrolladores y no desarrolladores que están desarrollando un software grande y complejo. BDD es muy útil para comunicar un modelo y su dominio en el mismo nivel a todos en el equipo, incluso si no saben nada sobre computadoras.

Si ese no es su caso, no use pepino, porque no lo necesita. Usa rspec y capybara para probar tu código JS y tus pruebas de integración.

Answer 3

Es más fácil escribir especificaciones simples para métodos simples. Es mucho más fácil que escribir cukes.

Si mantiene sus métodos simples y mantiene sus especificaciones simples, al probar solo la lógica dentro de ese método, encontrará alegría en las pruebas unitarias.

Si algo es redundante, sus pruebas de pepino. Si ha probado modelos y lib, su software debería funcionar.

Answer 4

Por lo general, no desea tener historias de Cucumber y especificaciones de controlador RSpec / pruebas de integración. Escoja uno (generalmente Pepino es la mejor opción, excepto en ciertos casos especiales). Luego usa RSpec para tus modelos, y eso es todo lo que necesitas.

Answer 5

Probé métodos complejos de modelo / lib con rspec y luego la lógica de negocio principal en web con pepino, así que estoy seguro de que las características principales de la web funcionarán al 100%, y luego, si obtuve más tiempo y recursos, pruebo todo lo demás.

Answer 6

Rails tiene una base de código bien probada, así que evitaría volver a probar cosas que están cubiertas en esos pasos.

Por ejemplo, a menos que sea un código personalizado, no tiene sentido probar los resultados de las validaciones en unidades y niveles funcionales. Sin embargo, los probaría en el nivel de integración. Las características de pepino actúan como especificaciones para su proyecto, por lo que es bueno especificar que necesita una validación para xey, incluso si la implementación es una declaración de línea única en el modelo.