delphi - ¿Cómo iniciar la unidad de prueba de código antiguo y nuevo?
unit-testing dunit (5)
Admito que casi no tengo experiencia en pruebas de unidad. Hice un intento con DUnit hace un tiempo, pero me rendí porque había muchas dependencias entre las clases en mi aplicación. Es una aplicación Delphi bastante grande (alrededor de 1.5 millones de líneas fuente) y somos un equipo que la mantiene.
La prueba por ahora es realizada por una persona que la usa antes de liberar e informar errores. También he configurado algunas pruebas de GUI en TestComplete 6, pero a menudo falla debido a cambios en la aplicación.
Bold para Delphi se usa como marco de persistencia contra la base de datos. Todos estamos de acuerdo en que Unittesting es el camino a seguir y planeamos escribir una nueva aplicación en DotNet con ECO como marco de persistencia.
Simplemente no sé por dónde empezar con la prueba de unidad ... ¿Algún buen libro, URL, buenas prácticas, etc.?
Bueno, el desafío en las pruebas unitarias no es la prueba en sí, sino la escritura de un código comprobable . Si el código se escribió sin pensar en las pruebas, probablemente lo pasarás realmente mal.
De todos modos, si puedes refactorizar, refactoriza para que sea verificable. No mezcle la creación de objetos con la lógica siempre que sea posible (no sé Delphi, pero podría haber algún marco de inyección de dependencia para ayudar en esto).
Este blog tiene mucha información sobre las pruebas. Revisa este artículo por ejemplo (mi primera sugerencia se basó en él).
En cuanto a una sugerencia, intente probar primero los nodos de hoja de su código, esas clases que no dependen de otros. Deben ser más fáciles de probar, ya que no requieren burlas.
Cuando trabajas con código heredado, los objetos simulados son realmente útiles para construir pruebas unitarias.
Eche un vistazo a esta pregunta con respecto a Delphi y las simulaciones: ¿Cuál es su biblioteca de burlas de Delphi favorita?
Escribir pruebas unitarias para código heredado usualmente requiere mucha refactorización. El excelente libro que cubre este tema es " Trabajando eficazmente con el código heredado " de Michael Feather
Una sugerencia adicional: use una herramienta de cobertura de prueba unitaria para indicar su progreso en este trabajo. Sin embargo, no estoy seguro de cuáles son las buenas herramientas de cobertura para el código de Delphi. Supongo que esta sería una pregunta / tema diferente.
Para la prueba de unidad .Net lea esto: " El arte de la prueba unitaria: con ejemplos en .NET "
Sobre las mejores prácticas:
Lo que dijo es correcto: a veces, es difícil escribir pruebas unitarias debido a la dependencia entre las clases ... Entonces, escriba las pruebas unitarias justo después o justo antes ;-) la implementación de las clases. De esta manera, si tiene algunas dificultades para escribir las pruebas, ¡quizás significa que tiene un problema de diseño!
Uno de los enfoques más populares es escribir las pruebas unitarias a medida que modifica el código. Todos los códigos nuevos se someten a pruebas unitarias, y para cualquier código que modifique, primero escriba su prueba, verifíquela, modifíquela, vuelva a verificarla y luego escriba / arregle cualquier prueba que necesite debido a sus modificaciones.
Una de las grandes ventajas de tener una buena cobertura de prueba unitaria es poder verificar que los cambios que realice no rompan inadvertidamente otra cosa. Este enfoque le permite hacer eso, mientras enfoca sus esfuerzos en sus necesidades inmediatas.
El enfoque alternativo que he empleado es desarrollar mis pruebas de unidad a través de Co-Ops :)