Las herramientas de cobertura de código, como Emma, Cobertura y Clover, instrumentarán su código y registrarán qué partes se invocan ejecutando un conjunto de pruebas. Esto es muy útil y debería ser una parte integral de su proceso de desarrollo. Le ayudará a identificar qué tan bien su conjunto de pruebas cubre su código.
Sin embargo, esto no es lo mismo que identificar un código muerto real. Solo identifica el código cubierto (o no cubierto) por las pruebas. Esto puede darle falsos positivos (si sus pruebas no cubren todos los escenarios), así como falsos negativos (si sus pruebas acceden al código que en realidad nunca se usa en un escenario del mundo real).
Me imagino que la mejor manera de identificar realmente el código muerto sería instrumentar su código con una herramienta de cobertura en un entorno de ejecución en vivo y analizar la cobertura del código durante un período prolongado de tiempo.
Si está ejecutando en un entorno redundante de carga equilibrada (y si no, ¿por qué no?), Supongo que tendría sentido instrumentar solo una instancia de su aplicación y configurar su equilibrador de carga de modo que una porción aleatoria, pero pequeña, de sus usuarios se ejecutan en su instancia instrumentada. Si hace esto durante un período prolongado de tiempo (para asegurarse de haber cubierto todos los escenarios de uso del mundo real, tales variaciones estacionales), debería poder ver exactamente qué áreas de su código se accede bajo el uso del mundo real y qué partes realmente nunca se accede y, por lo tanto, el código muerto.
Nunca lo he visto personalmente, y no sé cómo se pueden usar las herramientas antes mencionadas para instrumentar y analizar el código que no se invoca a través de un conjunto de pruebas, pero estoy seguro de que sí.
