Medición de cobertura de código en Delphi
unit-testing code-coverage (6)
¿Te refieres a la cobertura del código de pruebas unitarias o código obsoleto? En general, creo que solo el código comprobable que tiene un fallo debe ser cubierto con una prueba unitaria (sí, me doy cuenta de que puede estar comenzando una guerra santa, pero ahí es donde estoy). Entonces ese sería un porcentaje bastante bajo.
Ahora el código obsoleto por otro lado es una historia diferente. El código añejo es código que no se usa. Lo más probable es que no necesites una herramienta para decirte esto por una gran cantidad de tu código, solo busca los pequeños puntos azules después de compilarlos en Delphi. Todo lo que no tenga un punto azul está rancio. En general, si el código no se está utilizando, entonces se debe eliminar. Entonces eso sería una cobertura de código del 100%.
Hay otros escenarios para el código obsoleto, como si tiene un código especial para manejar si la fecha llega a ser el 31 de febrero. El compilador no sabe que no puede suceder, por lo que lo compila y le da un punto azul. Ahora puedes escribir una prueba unitaria para eso, y probarla y podría funcionar, pero luego desperdiciaste tu tiempo por segunda vez (primero para escribir el código, segundo para probarlo).
Hay herramientas para rastrear qué rutas de código se usan cuando se ejecuta el programa, pero eso solo es confiable, ya que no todas las rutas de código se usarán todo el tiempo. Al igual que el código especial que tiene que manejar año bisiesto, solo se ejecutará cada cuatro años. Entonces, si lo sacas, tu programa se romperá cada cuatro años.
Supongo que realmente no respondí tu pregunta sobre DUnit y Code Coverage, pero creo que te he dejado con más preguntas de las que comenzaste. ¿Qué tipo de cobertura de código estás buscando?
ACTUALIZACIÓN: Si está tomando un enfoque de TDD, entonces no se escribe ningún código hasta que escriba una prueba, por lo que por naturaleza tiene 100 pruebas de cobertura. Por supuesto que el hecho de que cada método sea ejercido por una prueba no significa que se ejerza toda su gama de comportamientos. SmartInspect proporciona un método realmente fácil para medir qué métodos se llaman junto con el tiempo, etc. Es un poco menos de AQTime, pero no gratis. Con un poco más de trabajo de su parte puede agregar instrumentos para medir cada ruta de código (ramas de instrucciones "if", etc.) Por supuesto, también puede agregar su propio registro a sus métodos para lograr un informe de cobertura, y eso es gratis (bueno, espera por tu tiempo, que probablemente valga más que las herramientas). Si usa JEDI Debug, también puede obtener una pila de llamadas.
TDD realmente no se puede aplicar de forma retroactiva al código existente sin una gran cantidad de refactorización. Aunque los nuevos IDE de Delphi tienen la capacidad de generar comprobantes de prueba unitarios para cada método público, que luego le ofrece una cobertura del 100% de sus métodos públicos. Lo que coloque en esos talones determina qué tan efectiva es esa cobertura.
¿Hay alguna manera de medir la cobertura del código con DUnit? ¿O hay alguna herramienta gratuita que logre eso? ¿Qué usas para eso? ¿Qué código de cobertura usualmente usas?
Jim McKeeth: Gracias por la respuesta detallada. Estoy hablando de pruebas unitarias en el sentido de un enfoque TDD, no solo acerca de las pruebas unitarias después de que ocurre una falla. Estoy interesado en la cobertura del código que puedo lograr con algunas pruebas unitarias preescritas básicas.
Acabo de crear un nuevo proyecto de código abierto en Google Code con una herramienta de cobertura de código básico para Delphi 2010. https://sourceforge.net/projects/delphicodecoverage/
Ahora mismo puede medir la cobertura de línea, pero también estoy planeando agregar cobertura de clase y método.
Genera informes html con un resumen y una fuente marcada que le muestra qué líneas están cubiertas (verde), cuáles no (rojo) y el resto de las líneas que no tienen ningún código generado para ellas.
Actualización: a partir de la versión 0.3 de https://sourceforge.net/projects/delphicodecoverage/ , puede generar informes XML compatibles con el complemento Hudson EMMA para mostrar las tendencias de cobertura del código dentro de Hudson .
Actualización: la versión 0.5 trae correcciones de errores, mayor capacidad de configuración e informes limpios
Actualización: la versión 1.0 brinda soporte para emma output, cobertura de clases y métodos y cobertura de DLL y BPL
Descubrir funciona muy bien para mí. Apenas retarda su aplicación, a diferencia de AQTime. Esto puede no ser un problema para ti de todos modos, por supuesto. Creo que las versiones recientes de AQTime funcionan mejor a este respecto.
He estado usando Discover "durante años, trabajé excelentemente hasta e incluyendo BDS2006 (que fue la última versión anterior a XE * de Delphi que usé y sigo usando), pero su estado actual de apertura, no está claro cómo hacerlo funcionar con Versiones XE * de Delphi. Una pena realmente, porque me encantó esta herramienta, rápida y conveniente en casi todos los sentidos. Así que ahora me estoy moviendo a la cobertura de código Delphi ...
No conozco ninguna herramienta gratuita. AQTime es casi el estándar de facto para perfilar Delphi. No lo he usado, pero una búsqueda rápida encontró Discover for Delphi , que ahora es de código abierto, pero solo tiene cobertura de código.
Cualquiera de estas herramientas debería darle una idea de cuánta cobertura de código están obteniendo las pruebas de su unidad.
Uso Discover for Delphi y hace el trabajo, para pruebas unitarias con DUnit y pruebas funcionales con TestComplete.
Discover se puede configurar para ejecutarse desde la línea de comandos para la automatización. Como en:
Discover.exe Project.dpr -s -c -m