Obtén 100% en el cuestionario para continuar
Por qué la cobertura no es suficiente
Ejecuta las pruebas y observa el 100% de cobertura en ambos módulos, y después pregúntate qué es lo que la cobertura no te dice.
Tienes una suite que pasa. La pregunta natural que un equipo hace a continuación es: "¿cuánto del código está probado?" La respuesta habitual es la cobertura de código.
Midiendo la cobertura
Ejecuta el script de cobertura:
npm run test:coverageVas a ver una tabla de cobertura, y aquí está la parte sorprendente: ambos, src/leapYear.js y src/discount.js, reportan 100% en todas las columnas: instrucciones, ramas, funciones y líneas.
Solo por los números de cobertura, los dos módulos son indistinguibles. Ambos parecen perfectamente probados.
Lo que la cobertura realmente mide
La cobertura de código responde a una única pregunta, mecánica:
¿Esta línea fue ejecutada mientras las pruebas corrían?
Eso es genuinamente útil. La cobertura encuentra código que ninguna prueba toca en absoluto, y eso vale la pena saberlo.
Pero observa lo que la cobertura no pregunta:
¿El resultado de esa línea fue alguna vez verificado?
Una prueba puede ejecutar una línea y luego no afirmar nada significativo sobre ella. Una prueba puede recorrer una rama en un valor seguro, pero nunca en el límite donde se esconde un bug. En ambos casos la línea queda verde en el reporte de cobertura, y un defecto real puede estar justo ahí debajo.
👨🏫 Esta es la idea central de todo el curso. La cobertura mide ejecución. No mide verificación. Dos suites con una cobertura idéntica del 100% pueden tener capacidades muy diferentes de detectar bugs.
La brecha, hecha concreta
El módulo discount.js tiene tres límites de regla de negocio y un mensaje de error. Sus pruebas ejecutan cada línea, así que la cobertura es del 100%. Aun así, como vas a ver, cuatro pequeños cambios en ese código pasan completamente desapercibidos para las pruebas. El sello de cobertura permanece verde mientras el comportamiento se rompe en silencio.
Lo que necesitamos es una forma de medir las aserciones, no la ejecución. Esa medición se llama testing de mutación, y la vas a ejecutar en la siguiente lección.
Visión general de los comandos 📖
npm run test:coverage
Ejecuta la suite de Jest y reporta cuánto del código fuente fue ejecutado por las pruebas.
Sintaxis:
npm run test:coverageEjemplo:
npm run test:coverageContenido sugerido 📚
- Jest - Configurando la cobertura de código
- ¿Qué es el testing de mutación? - documentación de Stryker
Ejercicio 🎯
Ejecuta npm run test:coverage y lee la tabla. Confirma que ambos módulos reportan 100% de cobertura.
Después abre src/discount.test.js y, solo leyendo, intenta identificar una regla de negocio que se ejecuta pero nunca se verifica en su límite exacto. Anota tu suposición. Pronto la vas a contrastar con el reporte de Stryker.
🙊 Los cuatro puntos débiles son los límitestotal < 0,total >= 100yprice < 50, además del mensaje de error lanzado para un total negativo. No te preocupes si no los detectaste todos a simple vista, ese es justamente el punto.
Muéstrale al mundo lo que aprendiste 🌎
Para mostrarle a tu red profesional lo que aprendiste en esta lección, publica lo siguiente en LinkedIn.
Estoy haciendo el curso "Testing de Mutación con Jest y Stryker" con @Walmyr Lima e Silva Filho en la @Talking About Testing School, donde aprendí que la cobertura de código mide si una línea fue ejecutada, no si su comportamiento fue verificado. #TalkingAboutTesting #TATSchool #MutationTesting #MutationTestingWithJestAndStryker
👨🏫 Recuerda mencionarme en tu publicación. Aquí está mi perfil de LinkedIn.
Cuestionario
¿Qué mide realmente la cobertura de líneas?
Obtén 100% en el cuestionario para continuar