Test de cobertura

Me costó ubicar el test de cobertura, porque lo escuchaba en diferentes entornos. Ahora ya lo veo mas o menos claro, y he sacado mis propias conclusiones. Hay muchas maneras de cubrir el producto al hacer las pruebas y cada método de cobertura es diferente y tiene su propia dinámica.

En conversaciones de calidad con CEOS y directivos no puedes utilizar el mismo argot que utilizas con tus compañeros. A ellos, no les importa si hay bugs abiertos o que es lo que queda por testear, ven el testing como un paso en la creación de software, justo como si fuera una caja negra. Necesitan métricas muy diferentes a las relacionadas con los procesos diarios para poder tomar decisiones. La gracia radica, en definir un test de cobertura con buenas métricas cuantitativas y cualitativas, esto dependerá del tipo de proyecto, de su estado y de como el CEO esté implicado.

Por otro lado, también se utiliza para hablar de las pruebas unitarias. Muchas herramientas de análisis de código sacan ésta métrica, por ejemplo SonarQube. En todos los daily meetings, escuchas la pregunta de si la cobertura de pruebas es alta. Lo que te dice esta métrica es qué líneas de código se han ejecutado al menos una vez al lanzar las pruebas unitarias y qué líneas no se han ejecutado nunca. Para mí es útil, para ver en qué puntos de la aplicación falta por desarrollar pruebas unitarias, pero no para ver la calidad de las pruebas que ya hemos hecho. Ya que mayor cobertura no significa mayor calidad. Puede que haya un 100% de cobertura, pero que realmente falte la mitad de requerimientos por desarrollar.