Code Coverage o cómo engañarte a ti mismo

Viene siendo muy habitual pensar que las pruebas son sinónimo de corrección y que es importante tener una gran cobertura de código. Voy a tratar de demostrar que esto no es así.

Ojo… con ello no digo que estén mal, sino que es necesario saber de qué estamos hablando. Yo soy partidario de un número de pruebas adecuado y de un porcentaje de cobertura… suficiente.

Si está probado, funciona

Sabemos que está probado, pero… ¿cubrimos todos los casos de uso? ¿Hemos cometido un error en las pruebas? ¿Se ha modificado el código después de realizar las pruebas?

Pasar las pruebas no es sinónimo de correctitud. No pasar las pruebas sí es sinónimo de error. El error puede estar en las pruebas o en el código, pero es una llamada de atención sobre aquéllo que debemos revisar.

Si encontramos un problema no contemplado en las pruebas, deberíamos añadirlo a la batería para que no vuelva a ocurrir.

Cobertura del 100%

Una cobertura de código amplia no puede ser mala. Lo malo puede ser no saber cómo interpretarlo.

Nuevamente, no podemos tomar por buena la definición en positivo, sino que hay que tomarla en negativo: No significa que cada línea de código por la que pasamos esté probada. Signfica que cada línea de código por la que no pasamos, no está probada en absoluto.

Por poner un ejemplo muy sencillo: Tenemos una simple división de tipo : a / b. En esta operación, a vale 3 y b vale 1. El porcentaje de cobertura es del 100%, pero es evidente que fallará cuando b valga 0.

Conclusión

Así que las pruebas están bien, y la cobertura está bien, pero sólo si sabemos realmente lo que significan.

¿Cuál es el porcentaje de cobertura adecuado? Todos sabemos que el porcentaje bueno de cobertura es el 80%, ¡¡y no menos!! (traducido por mí, si queréis)