Esta herramienta es muy útil. Nos ayuda a ver que porcentaje de nuestro código esta realmente siendo ejecutado. Hay código que nunca se toca y esto nos puede indicar tres cosas.
1. Es código que realmente no se usa y sólo estorba y perjudica a la mantenibilidad de nuestro proyecto. Solución: Borralo.
2. Es código que no se está probando. Solución: Crea una nueva prueba.
3. El código es tan simple que no hace falta probarlo. Esto pudiera ser real, sin embargo, si en todo el set de pruebas no se pasa nunca por ahí nos hace pensar que tal vez nunca se usa en toda la aplicación.
El punto uno es simple, solo no le agarren cariño al código que no sirve y presionen delete sin llorar por las horas que invirtieron en algo que nadie usara. El punto dos se puede cumplir de muchas formas, la ideal es una prueba unitaria que podamos repetir constantemente, sin embargo, podríamos hacer un WebTest o Manual Test, lo importante es que se pruebe.
Podemos ver un ejmplo reciente.
En este caso vemos que nuestro metodo Borrar Artículo siempre se esta probando cuando el baseNode no tiene un artículo. Esto pudiera no ser muy critíco porque los otros tres metodos si estan cubiertos por otras pruebas, sin embargo, es una prueba básica que debería estar considerada.
No es necesario llevar esta practica a un extremo y querer tener 100% Code Coverage, en muchos proyectos no vale la pena, sobre todo con código heredado o si no se inicio con buenas prácitcas. Lo que si debemos tener bien presente es que no baje nuestro code coverage, es decir, iteración tras iteración o mejor aún (Si usan Integración Continua) check-in tras check-in nuestro porcentaje de cobertura aumente, esta es una buena metrica para el equipo completo.
Links
Como Configurar Code Coverage en Team System (MSDN)
Configurar Integración Continua en Team System 2005
Configurar Integración Continua en Team System 2008
Code Coverage para NCover (Si pruebas con NUnit)
Entradas
Suscribete
No hay comentarios.:
Publicar un comentario