Cobertura de Código: Tipos y Configuración en Vitest
Contenido del curso
Comando para instalar la dependencia de desarrollo que permite generar reporte de coverage de test del proyecto.
yarn add @vitest/coverage-v8
David Galvan
Juan Gómez Carrillo
Juan Gómez Carrillo
Mariana Valencia Gallego
Juan Diego Mejia Maestre
Andres Gallego
Wilmer Garzon Cabezas
Team Platzi
Salome Arboleda
Test Coverage se refiere a la medida que indica qué tan bien los tests abarcan el código de un proyecto. Hay varios tipos:
Statement Coverage: Mide el porcentaje de declaraciones ejecutadas por los tests. Esto asegura que cada línea de código se prueba al menos una vez.
Branch Coverage: Evalúa si todas las ramas lógicas (como if-else) se han probado. Esto garantiza que tanto los caminos verdaderos como los falsos se ejecuten.
Function Coverage: Indica la proporción de funciones que han sido llamadas durante las pruebas. Es crucial para asegurar que todas las funciones estén testeadas.
Line Coverage: Similar a Statement Coverage, pero se enfoca en si cada línea del código ha sido ejecutada por los tests.
Un buen Test Coverage es vital para la calidad del software y para detectar errores.
Forzar un threshold es un arma de doble filo 🫠
Querer imponer un alto porcentaje normalmente solo hará que tu equipo de desarrollo sea más "perezoso" y hagan tests de dudosa calidad solo para llegar al threshold y poder desplegar su desarrollo.
Un porcentaje alto de cobertura no significa que los tests te estén protegiendo al 💯, solo significa que se pasó por esas líneas de código durante la ejecución de los tests .. ¡nada más! 😉
Mejor que imponer un porcentaje mínimo es crear cultura de testing, hacer conscientes a los desarrolladores del beneficio y la tranquilidad que aportan (además de servir como documentación).
Producto y los Engineer Managers deberían fomentar esa cultura de pruebas y dar el tiempo a los desarrolladores para que cubran sus desarrollos con tests de calidad.
Forzar un threshold es un arma de doble filo 🫠
Querer imponer un alto porcentaje normalmente solo hará que tu equipo de desarrollo sea más "perezoso" y hagan tests de dudosa calidad solo para llegar al threshold y poder desplegar su desarrollo.
Un porcentaje alto de cobertura no significa que los tests te estén protegiendo al 💯, solo significa que se pasó por esas líneas de código durante la ejecución de los tests .. ¡nada más! 😉
Mejor que imponer un porcentaje mínimo es crear cultura de testing, hacer conscientes a los desarrolladores del beneficio y la tranquilidad que aportan (además de servir como documentación).
Producto y los Engineer Managers deberían fomentar esa cultura de pruebas y dar el tiempo a los desarrolladores para que cubran sus desarrollos con tests de calidad.
Gran comentario. Cuando uno lleva mucho tiempo desarrollando se da cuenta de esto y la calidad mediocre de los tests cuando se fuerza el coverage
¡Excelente adición para tu stack, Juan Diego! Como estás trabajando con Vitest, el paquete @vitest/coverage-v8 es la opción estándar y más rápida actualmente para obtener métricas de calidad de código.
Aquí tienes el resumen en texto plano para tus notas de Notion:
📊 Reportes de Cobertura con Vitest
El "Coverage" es una métrica que indica qué porcentaje de tu código fuente es ejecutado durante las pruebas. Es fundamental para identificar "zonas muertas" o lógica de negocio que no ha sido validada.
📦 Instalación y Comando
Para proyectos que usan Yarn (como el tuyo), la instalación se realiza como dependencia de desarrollo:
Bash
yarn add -D @vitest/coverage-v8
Para ejecutarlo y ver el reporte en la terminal:
Bash
yarn vitest run --coverage
⚙️ Configuración Sugerida (vitest.config.ts)
No basta con instalarlo; para sacarle provecho en Código Limpio, te recomiendo configurar los umbrales (thresholds) en tu archivo de configuración:
TypeScript
export default defineConfig({ test: { coverage: { provider: 'v8', // El motor que instalaste reporter: ['text', 'json', 'html'], // Formatos de salida all: true, // Incluye archivos que no tienen tests aún thresholds: { lines: 80, // El test fallará si tienes menos del 80% de cobertura functions: 80, branches: 80, statements: 80, }, }, }, });
💡 ¿Por qué usar V8 sobre Istanbul?
Existen dos proveedores principales, pero V8 es el preferido por los desarrolladores modernos por estas razones:
🔍 Tipos de Cobertura que verás en tu reporte
if o un operador ternario (ej: renderizado condicional).Al tratar de usar el V8 tuve muchos errores de consola y nunca me generó bien el reporte, hice el cambio para istanbul y dio, les dejo la documentacion.
Perfect! Muchas gracias por tu aporte <u>Andrés</u> 💚
¿Por qué en las métricas de mi coverage no me salió ese archivo “callboocks.ts”, solo lo ignoro?