Spring GDS 25 Aniversario
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Cobertura de tests
¿Qué es la cobertura de tests?
La cobertura de tests mide cuánto de tu código se ejecuta cuando corre la suite de tests, normalmente como porcentaje. La cobertura de líneas rastrea qué líneas corrieron. La de ramas rastrea si se tomaron ambos lados de cada if/else. La de funciones rastrea qué funciones se llamaron siquiera. Una herramienta instrumenta el código, corre los tests e informa de la parte que los tests tocaron de verdad.
El número es útil y fácil de malinterpretar. Una cobertura alta te dice que los tests pasan por la mayor parte del código. No te dice que comprueben las cosas correctas. Un test puede ejecutar una función, no afirmar nada con sentido y aun así contar para el 100%. Ahí está la trampa: la cobertura mide ejecución, no corrección. Un módulo de pagos al 95% de cobertura puede aún publicar un bug si ninguno de esos tests verifica el importe real cobrado. La cobertura te muestra qué no se probó nunca, lo cual es genuinamente valioso, pero un número verde es un suelo, no una garantía.
Perseguir el 100% rara vez compensa. El último tramo suele significar escribir tests para getters triviales y ramas de error que nunca se dispararán de forma realista, lo que cuesta tiempo y añade ruido. La mayoría de equipos fija un umbral sensato, vigila las caídas bruscas que señalan código nuevo sin probar y gasta su esfuerzo real en asegurar que las rutas importantes tengan tests que afirmen algo que valga la pena afirmar.
Cobertura de tests en Dallonses
Usamos la cobertura como una señal, nunca como un marcador. Un informe de cobertura es bueno en una cosa: mostrar el código que tus tests no han tocado nunca. Lo leemos así, miramos qué falta en las rutas que cargan el riesgo real y escribimos tests que verifican comportamiento en lugar de solo recorrer las líneas.
No perseguimos un número por sí mismo, y se lo decimos al cliente que pide el 100%. Una suite trucada para alcanzar un objetivo parece tranquilizadora y no protege nada. Nuestro testing automatizado enfoca la cobertura donde el fallo de verdad dolería, los flujos de dinero y la lógica central, y la mantiene honesta con aserciones que fallarían genuinamente si el código se rompiera. El sentido del informe es menos bugs en producción, no un dashboard más bonito.
¿Tienes un número de cobertura alto del que no estás seguro de poder fiarte? Pongámoslo a prueba.
Servicios relacionados
Trabajos relacionados
Vizitio
Convertir una marca en un negocio que funciona.
Access Ticket
Medio millón de personas. Una app. Cero caos.
¿Listo para trabajar juntos?
Reservar una reunión
