Entendiendo el % de Cobertura en Unit Tests con Jest y TypeScript

Hace unas semanas tomé una tarea que hablaba sobre mejorar la cobertura de los unit tests para un repositorio que se encarga de la creación y mantenimiento de un lambda en AWS. Andábamos cortos de Dev y tuve que llenar el hueco 🤷🏻‍♂️.

Lo primero que me encontré es que había funciones ENORMES y que, esas funciones, llamaban otras funciones privadas dentro de la misma clase. Ahora...algo que me llamó la atención porque no me acordaba que era así es que, OBVIO, las funciones privadas son tenidas en cuenta para el % de statement sobre todo.

La cobertura de pruebas unitarias es un concepto clave en el desarrollo de software, pero a menudo se mezclan los conceptos y se bardea. En este post, quería explorar cómo Jest y TypeScript calculan la cobertura, cómo los métodos privados afectan este cálculo y qué mejores prácticas seguir para mantener un código bien probado sin caer en métricas engañosas.

¿Qué es el % de cobertura en Unit Tests?

El porcentaje de cobertura indica cuánto del código ha sido ejecutado por pruebas unitarias. Jest, al igual que otras herramientas, genera un reporte de cobertura con distintos tipos de métricas en nuestra vieja y querida terminal:

• Statements: Porcentaje de sentencias ejecutadas.

• Branches: Cobertura de estructuras de control (if, switch, loops).

• Functions: Cobertura de funciones ejecutadas.

• Lines: Porcentaje de líneas de código ejecutadas.

Podés generar un reporte de cobertura en Jest ejecutando:

jest --coverage

¿Los métodos privados afectan la cobertura?

En TypeScript, los métodos privados sí afectan la cobertura de código. Aunque no pueden ser llamados directamente en las pruebas unitarias, si son invocados internamente por métodos públicos que sí están probados, entonces también contarán para la cobertura.

Veamos un ejemplo:

class Calculadora {
  private sumar(a: number, b: number): number {
    return a + b;
  }

  public calcularSuma(a: number, b: number): number {
    return this.sumar(a, b);
  }
}

Si escribimos pruebas solo para calcularSuma, Jest marcará que sumar también está cubierto, porque se ejecuta indirectamente:

test('calcularSuma debe devolver la suma de dos números', () => {
  const calc = new Calculadora();
  expect(calc.calcularSuma(2, 3)).toBe(5);
});

¿Se deben probar los métodos privados directamente?

No es recomendable. Las pruebas unitarias deben enfocarse en la interfaz pública de la clase. Si necesitas probar un método privado directamente, probablemente ese método debería ser parte de otra clase.

Buenas prácticas

1. No obsesionarse con la cobertura del 100%: La cobertura es una guía, no una garantía de calidad (y tengo bastante más para decir sobre esto después de haber estado trabajando bastante en Unit Testing...)

2. Probar casos reales de uso: Enfócate en probar la funcionalidad esperada a través de la interfaz pública.

3. Evitar exponer métodos privados solo para probarlos: Si un método privado es crítico, revisa si podría moverse a otra clase y hacerse público.

4. Revisar la cobertura de ramas (branches): Asegúrate de probar todas las condiciones posibles.

En mi caso, dado que los métodos privados estaban ahí para hacer algo específico, dediqué mis esfuerzos a crear mocks de las funciones privadas, usando el mockResolvedValueTo para preparar el contexto de la forma que necesitara para la validación final. Ya se que dije que no hay que obsesionarse con el 100%...pero ese repo terminó con 95% de statement coverage 🔥

En resumen, la cobertura es una herramienta valiosa, pero no debe ser el único criterio para evaluar la calidad de nuestras pruebas. En próximos posteos me vas a leer enojado con cómo se hacen los unit tests, lo que se pasa por alto y por qué hay que insistir con hacer Test Driven Development en el desarrollo de software.

Por ahora...toca ir a la pileta. ¡Nos vemos!