Cobertura de Código: Tipos y Configuración en Vitest

Clase 19 de 20 • Curso de React Testing Library

Contenido del curso

Fundamentos del Testing en React

Estrategias de Testing en React

Testing de Flujos de Usuario en React

Testing de Hooks en React

Pruebas de Integración y APIs en React

Reflexiones sobre Testing en React

Tomar examen

Resumen

Comando para instalar la dependencia de desarrollo que permite generar reporte de coverage de test del proyecto.

yarn add @vitest/coverage-v8

Comentarios

David Galvan

student•

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.

Juan Gómez Carrillo

student•

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.

Juan Gómez Carrillo

student•

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.

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.

Mariana Valencia Gallego

student•

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

Juan Diego Mejia Maestre

student•

¡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:

Velocidad: V8 utiliza el motor nativo de Node.js, lo que lo hace significativamente más rápido en proyectos grandes.
Precisión: Maneja mejor las transformaciones de TypeScript y sintaxis moderna de JavaScript.
Cero Instrumentación: A diferencia de Istanbul, no necesita "ensuciar" tu código con contadores adicionales antes de ejecutarlo.

🔍 Tipos de Cobertura que verás en tu reporte

Lines: Porcentaje de líneas de código ejecutadas.
Statements: Porcentaje de sentencias (un solo renglón puede tener varias).
Functions: Cuántas de tus funciones fueron llamadas.
Branches: Crucial en React. Mide si probaste ambos lados de un if o un operador ternario (ej: renderizado condicional).

Andres Gallego

student•

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.

Wilmer Garzon Cabezas

Team Platzi•

Perfect! Muchas gracias por tu aporte <u>Andrés</u> 💚

Salome Arboleda

student•

¿Por qué en las métricas de mi coverage no me salió ese archivo “callboocks.ts”, solo lo ignoro?

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,
      },
    },
  },
});

Cobertura de Código: Tipos y Configuración en Vitest

Fundamentos del Testing en React

Pruebas de Frontend con React: Evita Errores Críticos

Testing de Aplicaciones con Vitest y React

Estructura y Creación de Tests en JavaScript con Vitest

Estrategias de Testing en React

Pruebas de Componentes en React con Testing Library

Testing con Table Driven en React: Mejora Mantenibilidad y Cobertura

Desarrollo Orientado a Pruebas (TDD) en React paso a paso

Uso de Mocks en Testing de Software

Testing de Flujos de Usuario en React

Pruebas de Error en Login con React y Vitest

Pruebas de Login Exitoso en Aplicación Web

Testeo de Órdenes en Dashboard con Vitest y React Testing Library

Testeo de Componentes para Administradores en Platzi Orders

Testing de Hooks en React

Principios SOLID para código limpio y mantenible en desarrollo software

Testeo de Custom Hooks con Testing Library React Hooks

Testing con Spies en React: Verificación de Funciones y Errores

Pruebas de Integración y APIs en React

Configuración de Mock Service Worker para Pruebas en Visual Studio Code

Pruebas de React con Mock Service Worker y Hooks

Pruebas de Error 500 en Endpoints con Mock Service Worker

Reflexiones sobre Testing en React

Testing con Inteligencia Artificial en React

Cobertura de Código: Tipos y Configuración en Vitest

Cuándo y cómo implementar test en proyectos de React