Recientemente comencé a usar herramientas de cobertura de código (especialmente Emma y EclEmma), y realmente me gusta la vista que me da sobre la integridad de mis pruebas de unidad y la capacidad de ver qué áreas del código mi unidad prueba no están pegando en absoluto. Actualmente trabajo en una organización que no realiza muchas pruebas unitarias, y tengo la intención de presionar a todos para que realicen las pruebas unitarias y la cobertura de códigos y TDD y, con suerte, convierta la organización.¿Qué distancia toma la cobertura del código?
Un problema que no estoy seguro con este tema es exactamente qué tan lejos debo tomar la cobertura de mi código. Por ejemplo, si tengo una clase como esta:
//this class is meant as a pseudo-enum - I'm stuck on Java 1.4 for time being
public final class BillingUnit {
public final static BillingUnit MONTH = new BillingUnit("month");
public final static BillingUnit YEAR = new BillingUnit("year");
private String value;
private BillingUnit(String value) {
this.value = value;
}
public String getValue() {
return this.value;
}
public boolean equals(Object obj) {
return value.equals(((BillingUnit) obj).getValue());
}
public int hashCode() {
return value.hashCode();
}
}
me escribió algunas pruebas unitarias simples para asegurarse de que funciona correctamente equals(), que vuelve getValue() lo que esperaba, etc, pero gracias a la naturaleza visual de EclEmma , el método hashcode() aparece como rojo brillante para "no probado".
¿Vale la pena incluso molestarse en probar hashCode(), en este ejemplo, considerando cuán simple es la implementación? Siento que estaría agregando una prueba unitaria para este método simplemente para aumentar la cobertura del código% arriba, y deshacerme de la luz roja deslumbrante que EclEmma agrega a estas líneas.
Tal vez estoy siendo neurótico y OCD, pero encuentro que usar algo como EclEmma hace que sea tan fácil ver lo que no se ha probado: el complemento resalta el código fuente en rojo y el código cubierto en verde, realmente me da ganas de presionar para obtener tantas clases 100% ecológicas como pueda, incluso cuando no aporten mucho beneficio.
Creo que este es un buen punto. Aunque para manejar esto, hice algo de mi objetivo emma y utilicé una configuración de log4j con el registrador de raíz establecido en DEPURAR, y los filtros del appender en el nivel DESACTIVADO (para que todas las sentencias log.debug() sean accionadas, pero no registradas en ninguna parte) . –
Todavía se encontrará con problemas, porque si revisa el nivel de registro, siempre se evaluará como verdadero (o falso, dependiendo de la configuración), por lo que la cobertura de su sucursal será solo del 50%. –
Pero no estoy haciendo ninguna rama, no hay más para si (log.isDebugEnabled()) - ¿verdad? –