Contenido del curso
Cobertura de Código: Tipos y Configuración en Vitest
Comando para instalar la dependencia de desarrollo que permite generar reporte de coverage de test del proyecto.
yarn add @vitest/coverage-v8
David Galvan
Estudiante
Juan Gómez Carrillo
EstudianteJuan Gómez Carrillo
Estudiante
Mariana Valencia Gallego
Estudiante
Juan Diego Mejia Maestre
Estudiante
Andres Gallego
Estudiante
Wilmer Garzon Cabezas
Team Platzi
Salome Arboleda
EstudianteTest 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?