¿Cómo encontrar el código que sólo se llame de pruebas

Question

De vez en cuando estoy mirando algo de código, busco usos de un método (usando ReSharper) y parece que sólo es llamado por pruebas. Por lo que es efectivamente redundante y puede eliminarlo y los métodos que llaman.

Es evidente que no hay razón para tener código no utilizado por ahí el lugar, lo que frena la construcción y la prueba de funcionamiento. Lo que me gustaría es una herramienta que me puede decir donde todos los bits del código de producción son que sólo se accede por medio de pruebas.

Tengo una versión completa de ReSharper, y también una versión de prueba de NDepend, pero no han encontrado la manera de utilizar cualquiera de estos para obtener el resultado que quiero (sin pagar por ello). Sospecho que puede ser posible con la versión completa de NDepend pero ¿existen otras herramientas que la gente conozca?

Si el contexto de ayuda, la solución es y el sitio web ASP.net, gran parte de cuya funcionalidad está a cargo de un servicio WCF. Por lo que los puntos de entrada solamente válidas a la mayor parte del código son los métodos de servicio. Las pruebas están en sus propios proyectos separados.

he comenzado una recompensa porque estoy seguro de que alguien más debe haber tenido y resuelto este problema antes!

Answer 1

manualmente mirando con NDepend debe trabajar con el Dependency Matrix. Allí se puede ver qué métodos se utilizan sólo por las Asambleas de prueba de unidad.

No estoy seguro de si se puede escribir propias consultas CQL con la versión de prueba. Pero con la versión Pro se puede utilizar una consulta como la siguiente:

SELECT METHODS WHERE IsUsedBy "ASSEMBLY:NAME_OF_THE_UNIT_TEST_ASSEMBLY" 
AND !(IsUsedBy "ASSEMBLY:NAME_OF_ANOTHER_ASSEMBLY" OR IsUsedBy "ASSEMBLY:ANOTHER_NAME")

Para que esto funcione hay que crear un proyecto NDepend que conoce todas sus asambleas.

Para NAME_OF_THE_UNIT_TEST_ASSEMBLY usted tiene que insertar su Asamblea Prueba de la unidad y en la segunda parte tiene que especificar que la producción ensamblados de código con IsUsedBy y separados con OR.

Answer 2

Un enfoque no técnica sería la de que quitar temporalmente proyecto de prueba de su solución, a continuación, utilizar el análisis de código de Visual Studio (o FxCop) para localizar cualquier método que no están siendo llamados por cualquier otra cosa.

Answer 3

Se podría utilizar NDepend con algunas consultas personalizadas ... Eso es justo al lado de la parte superior de mi cabeza, nunca utilizado para exactamente eso, pero debería funcionar.