Medición de la cobertura del código en Delphi

Question

¿Hay alguna forma de medir la cobertura del código con DUnit?¿O existen herramientas gratuitas que lo logren?¿Qué usas para eso?¿Qué cobertura de código suele elegir?

Jim McKeeth:Gracias por la respuesta detallada.Me refiero a pruebas unitarias en el sentido de un enfoque TDD, no solo a pruebas unitarias después de que se produjo una falla.Estoy interesado en la cobertura de código que puedo lograr con algunas pruebas unitarias básicas escritas previamente.

Answer 1

Acabo de crear un nuevo proyecto de código abierto en Google Code con una herramienta de cobertura de código básica para Delphi 2010. https://sourceforge.net/projects/delphicodecoverage/

En este momento puede medir la cobertura de líneas, pero también planeo agregar cobertura de clases y métodos.

Genera informes html con un resumen y una fuente marcada que muestra qué líneas están cubiertas (verde), cuáles no (rojo) y el resto de las líneas que no tenían ningún código generado para ellas.

Actualizar:A partir de la versión 0.3 de Cobertura del código Delphi puede generar informes XML compatibles con el complemento Hudson EMMA para mostrar las tendencias de cobertura de código dentro hudson.

Actualizar:La versión 0.5 trae correcciones de errores, mayor capacidad de configuración e informes limpios

Actualizar:La versión 1.0 brinda soporte para la salida de Emma, ​​cobertura de clases y métodos y cobertura de DLL y BPL.

Answer 2

No sé de ninguna herramienta libres. AQTime es casi el estándar de facto para el perfil de Delphi. No he usado, pero una búsqueda rápida encontrado Discover para Delphi , que ahora es de código abierto, pero sólo lo hace la cobertura de código.

Cualquiera de estas herramientas te dará una idea de la cantidad de cobertura de código pruebas unitarias están recibiendo.

Answer 3

¿Se refiere a la cobertura de código de pruebas unitarias o código rancio? En general, creo que sólo el código comprobable que tiene un fallo que deben estar cubiertos con una prueba de unidad (sí soy consciente de que puede estar empezando una guerra santa, pero que es donde estoy). Por lo que sería un porcentaje bastante bajo.

Ahora código rancio por el contrario es una historia diferente. rancio código es el código que no se acostumbra. Lo más probable es que no necesita una herramienta para decirle esto para una gran parte de su código, sólo tiene que buscar los pequeños puntos de color azul después se compila en Delphi. Nada sin un punto azul es rancio. En general, si el código no se está usando, entonces debe ser eliminado. Por lo que sería el 100% de cobertura de código.

Hay otros escenarios para el código rancio, como si tiene código especial para manejar si la fecha nunca cae en el 31 de febrero. El compilador no sabe que no puede suceder, por lo que lo compila y le da un punto azul. Ahora se puede escribir una prueba unitaria para eso, y lo prueba y que podría funcionar, pero entonces usted acaba de perder su tiempo por segunda vez (la primera para escribir el código, el segundo para probarlo).

Existen herramientas para rastrear lo que las rutas de código se acostumbran cuando el programa se ejecuta, pero eso es sólo simi-fiable ya que no todas las rutas de código se acostumbrará cada vez. Al igual que el código especial que usted tiene que manejar año bisiesto, que sólo se ejecutará cada cuatro años. Así que si lo sacas a continuación, su programa se divide cada cuatro años.

Creo que realmente no responder a su pregunta sobre DUnit y cobertura de código, pero yo creo que puede que te he dejado con más preguntas entonces que empezó. ¿Qué tipo de cobertura de código está buscando?

ACTUALIZACIÓN: Si usted está tomando un enfoque TDD entonces ningún código está escrito hasta que escribir una prueba para él, así que por naturaleza tiene una cobertura de prueba 100. Por supuesto, sólo porque cada método se ejerce mediante una prueba no significa que toda su gama de comportamientos se ejerce. SmartInspect proporciona un método muy fácil de medir que métodos se denominan a lo largo con la sincronización, etc. Es un poco menos de AQTime, pero no libre. Con un poco más de trabajo de su parte puede agregar instrumentación para medir cada ruta de código (ramas de sentencias "if", etc.) Por supuesto, también puede simplemente añadir su propio registro a sus métodos para lograr un informe de cobertura, y que es libre (bueno, esperar por su tiempo, que es probablemente vale más que las herramientas). Si utiliza JEDI depuración entonces se puede obtener una pila de llamadas también.

TDD realmente no puede ser fácilmente aplicada retroactivamente al código existente sin necesidad de una gran cantidad de refactorización. A pesar de los nuevos entornos de desarrollo de Delphi tienen la capacidad de generar recibos de pruebas unitarias para cada método público, que a su vez le da una cobertura del 100% de sus métodos públicos. Lo que se pone en los talones determina la forma en que la cobertura efectiva es.

Answer 4

Discover para Delphi y lo hace el trabajo, para las pruebas unitarias con DUnit y prueba funcional con TestComplete.

Discover se puede configurar para ejecutar desde la línea de comandos para la automatización. Como en:

Discover.exe Project.dpr -s -c -m

Answer 5

Descubre funciona muy bien para mí. Difícilmente se ralentiza su aplicación, a diferencia de AQTime. Esto puede no ser un problema para usted de todos modos, por supuesto. Creo que las versiones recientes de AQTime se desempeñan mejor en este sentido.

Answer 6

He estado usando Descubrir" durante años, trabajó excelentemente hasta e incluyendo BDS2006 (que fue el último pre-XE * versiones de Delphi i utilizado y siguen utilizando), pero su estado opensourced actual, no está claro cómo hacer que funcione con XE * versiones de Delphi. Una pena, porque me encantaba esta herramienta, rápida y cómoda en casi todos los sentidos. Así que ahora me estoy mudando a delphi-código-cobertura ...