ruby on rails - software - ¿La mejor forma de agregar pruebas a un proyecto de Rails existente?
ruby on rails tutorial español (6)
¿Quizás comiences con las modelos? Deben ser verificables en forma aislada, lo que debería convertirlos en la fruta más baja.
A continuación, elija un modelo y comience a escribir pruebas que digan lo que hace. A medida que avance, piense en otras formas de probar el código: ¿hay casos extremos de los que tal vez no esté seguro? Escriba las pruebas y vea cómo se comporta el modelo. A medida que desarrolla las pruebas, es posible que vea áreas en el código que no están tan limpias y sin duplicar (DRY) como podrían ser. Ahora que tiene pruebas, puede refactorizar el código, ya que sabe que no está afectando el comportamiento. Trate de no comenzar a mejorar el diseño hasta que tenga las pruebas en su lugar, de esa manera se encuentra la locura.
Una vez que tengas los modelos inmovilizados, muévete hacia arriba.
Esa es una forma. Las alternativas pueden estar comenzando con vistas o controladores, pero puede que le resulte más fácil comenzar con pruebas de transacciones de extremo a extremo y trabajar en piezas cada vez más pequeñas a medida que avanza.
Tengo un proyecto de Rails para el que no hice pruebas (¡por vergüenza!) Y la base de códigos se ha vuelto bastante grande. Un amigo mío dijo que era difícil usar RSpec a menos que lo usara desde el principio. ¿Es esto cierto? ¿Qué lo haría decir eso?
Entonces, teniendo en cuenta las suites de pruebas disponibles y el hecho de que la base de códigos ya está allí, ¿cuál sería mi mejor curso de acción para hacer que esta cosa sea comprobable? ¿Es realmente tan diferente que hacerlo desde el principio?
Esta pregunta surgió recientemente en la lista de correo de RSpec, y el consejo que generalmente dimos fue:
- No se moleste en tratar de adaptar las especificaciones al código existente y que funciona, a menos que vaya a cambiarlo; es agotador y, a menos que el código deba cambiarse, no tiene sentido.
- Comience a escribir especificaciones para cualquier cambio que haga a partir de ahora. Las correcciones de errores son una oportunidad especialmente buena para esto.
- Trate de entrenarse en la disciplina que antes de tocar el código, antes que nada escriba un ejemplo de error (= especificación) para expulsar el cambio.
Puede encontrar que el diseño del código que no fue eliminado por ejemplos de código o pruebas unitarias hace que sea incómodo escribir pruebas o especificaciones. Esto es quizás a lo que se estaba refiriendo tu amigo. Es casi seguro que tendrá que aprender algunas técnicas clave de refactorización para romper las dependencias, de modo que pueda ejercitar cada clase aisladamente de sus especificaciones. El excelente libro de Michael Feathers, Working Effectively With Legacy Code contiene material excelente para ayudarlo a aprender esta delicada habilidad.
También te animo a utilizar la función especificada: rcov rake para generar estadísticas de cobertura de código. Es extremadamente gratificante ver cómo aumentan estos números cuando comienza a probar su base de código.
Escribir pruebas para el código existente puede revelar errores en su código. Estas pruebas le obligarán a mirar el código existente para que pueda ver qué prueba necesita escribir para que pase y puede ver algún código que posiblemente podría escribirse mejor o que ahora es inútil.
Otro consejo es escribir una prueba cuando encuentre un error por lo que nunca debe volver a ocurrir, esto se llama prueba de regresión.
La respuesta aceptada es un buen consejo, aunque no práctico en algunos casos. Recientemente me enfrenté con este problema en algunas aplicaciones mías porque NECESITO pruebas para el código existente. Simplemente no había otra forma de evitarlo.
Empecé haciendo todas las pruebas unitarias, luego pasé a funcionales.
Adquiera el hábito de escribir pruebas fallidas para cualquier código nuevo, o cada vez que vaya a cambiar una parte del sistema. Descubrí que esto me ayudó a obtener más conocimiento sobre las pruebas a medida que avanzo.
Usa rcov para medir tu progreso.
¡Buena suerte!
Actualizar las especificaciones no es inevitablemente una mala idea. Pasas del código de trabajo al código de trabajo con propiedades conocidas, lo que te permite saber si un cambio futuro rompe algo. Por el momento, si necesita hacer un cambio, ¿cómo puede saber lo que afectará?
Lo que las personas quieren decir cuando dicen que es difícil agregar pruebas / especificaciones al código existente es que el código que es difícil de probar a menudo está altamente acoplado, lo que hace que sea difícil escribir pruebas aisladas de bajo nivel.
Una idea sería comenzar con pruebas de pila completa usando algo como el corredor de historias RSpec. A continuación, puede trabajar desde el ''afuera'' aislando lo que pueda en pruebas aisladas de bajo nivel y, gradualmente, desenrede poco a poco el código más difícil.
Puede comenzar a escribir "pruebas de caracterización". Con esto, puede que probar la gema pretenciosa aquí :
Sin embargo, todavía es un trabajo en progreso.