¿Cómo determinar qué clases se beneficiarían más de las pruebas unitarias?

Question

Estoy trabajando en un proyecto en el que solo tenemos un 13% de cobertura de código con nuestras pruebas unitarias. Me gustaría idear un plan para mejorar eso, pero centrándome primero en las áreas donde aumentar la cobertura aportaría el mayor valor. Este proyecto está en C#, usamos VS 2008 y TFS 2008 y las pruebas de unidades externas se escriben usando MSTest.

¿Qué metodología debo usar para determinar qué clases debemos abordar primero? ¿Qué métricas (código o uso) debería estar viendo (y cómo puedo obtener esas métricas si esto no es obvio)?

Answer 1

Para algunas buenas estadísticas y consultas determinista de ciertos métodos que definitivamente se podría mirar NDepend: http://www.ndepend.com/

NDepend expone un lenguaje de consulta llamado CQL (lenguaje de consulta de código) que le permite escribir consultas contra su código relacionadas con ciertas estadísticas y análisis estático.

No hay una forma verdadera de determinar qué clases pueden ser más beneficiosas, sin embargo, al establecer sus propios umbrales en CQL puede establecer algunas reglas y convenciones.

Answer 2

Recomendaría agregar pruebas unitarias a todas las clases que toca, no retroadaptando las clases existentes.

La mayoría de las ventajas de las pruebas unitarias es ayudar a los programadores a codificar y garantizar que las "reparaciones" no rompan nada, si no se agrega código a una nueva sección de código que no se modifica, los beneficios de pruebas unitarias comienzan a caer.

Es posible que también desee agregar pruebas unitarias a las clases en las que confía si no tiene nada mejor que hacer.

Debe agregar pruebas a la nueva funcionalidad que agrega, pero probablemente también debería agregar pruebas a la funcionalidad existente que puede romper.

Si está haciendo un refactor grande, considere obtener una cobertura del 80-100% primero en esa sección.

Answer 3

El mayor valor de una prueba unitaria es para el mantenimiento, para garantizar que el código siga funcionando después de los cambios.

Por lo tanto, concéntrese en los métodos/clases que son más probables/más frecuentemente cambiados.

Las siguientes en importancia son las clases/métodos con lógica menos que obvia. Las pruebas unitarias se hacen menos frágil mientras que actúa como extra "documentación" de su API contraído

Answer 4

Organice todos sus componentes en niveles. Cada clase en un nivel dado solo debería depender de componentes de un nivel inferior. (Un "componente" es cualquier grupo lógico de una o más clases).

Primero, escriba pruebas unitarias para todos sus componentes de nivel 1. Por lo general, no necesita marcos de burla u otras tonterías porque estos componentes solo se basan en .NET Framework.

Una vez que haya terminado el nivel 1, comience en el nivel 2. Si las pruebas de nivel 1 son buenas, no necesitará burlarse de esas clases cuando escriba sus pruebas de nivel 2.

Continúe de la misma manera, ascendiendo en la pila de aplicaciones.

Consejo: Divida todos sus componentes en archivos DLL específicos de nivel.De esta forma, puede asegurarse de que los componentes de bajo nivel no asuman accidentalmente una dependencia de un componente de nivel superior.

Answer 5

En general, las pruebas de unidades son una herramienta para proteger contra la regresión y la regresión es más probable que ocurra en las clases con más dependencias. No debería tener que elegir, debería probar todas las clases, pero si tiene que hacerlo, pruebe las clases que tienen más dependencias en general.