¿Se está refiriendo 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%.
Existen 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).
Existen herramientas para rastrear qué rutas de código se utilizan cuando se ejecuta el programa, pero eso es solo 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 no respondí realmente a su pregunta sobre DUnit y Cobertura de código, pero creo que es posible que le haya dejado más preguntas con las que comenzó. ¿Qué tipo de cobertura de código estás buscando?
ACTUALIZACIÓN: Si está tomando un enfoque 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 fácilmente 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.
Todavía no acepté una de las respuestas, porque quiero alentar a la gente a escribir su opinión sobre pruebas unitarias, qué herramientas usan y qué cobertura ellos tratan de lograr. Entonces, todos, siéntanse libres de comentar;) – jpfollenius