Al escribir código de pruebas, llega un momento en que uno se obsesiona con la cifra de cobertura.
Entiendo muy bien esa sensación de pensar: «Ya que estamos, hay que llegar al 100%».
Para ir directamente a la conclusión, una cobertura de código del 70–80% es el objetivo más realista en la práctica, y el 100% no significa que el código esté libre de errores. Voy a explicar por qué basándome también en mi experiencia.
Primero, el resumen de las ideas clave
Para quienes tienen prisa, resumo primero la conclusión del artículo.
- Una cobertura del 100% solo significa que «se ejecutó cada línea», no que «se verificaron todos los casos».
- En la práctica, se recomienda generalmente alrededor del 70–80%.
- Para la lógica crítica, como pagos y autenticación, conviene aspirar al 90% o más.
- Es más importante saber «qué no se ha probado» que conocer la cifra.
¿Una cobertura de código del 100% significa que no hay errores?
Ese es el error más habitual.
Una cobertura del 100% solo significa que las pruebas «ejecutaron cada línea del código al menos una vez».
No significa que hayan verificado que cada línea funciona correctamente.
Veamos un ejemplo. En la siguiente función, la prueba ejecuta el código, pero no comprueba correctamente el resultado.
func divide(_ a: Double, _ b: Double) -> Double {
return a / b // bsi 0? La prueba se ejecuta, pero
}
// Esta prueba tiene cobertura 100%, pero
@Test func divide_solo ejecuta_el código() {
_ = divide(10, 2) // no verifica el valor devuelto(#expect)!
}Este código alcanza una cobertura del 100%.
Pero, como no comprueba el resultado mediante #expect, en realidad no garantiza nada.
La cobertura mide «cuánto se ejecutó», no «qué tan bien se verificó».
Por eso no debemos confiar únicamente en la cifra.
Entonces, ¿qué porcentaje es adecuado?
He resumido en una tabla el criterio realista que he experimentado tras pasar por varios equipos. (Recomendación práctica general a fecha de 2026)
| Área del código | Cobertura recomendada | Motivo |
|---|---|---|
| Lógica de negocio principal | 90% o más | Los errores en pagos o autenticación pueden ser críticos |
| Código general de servicios | 70~80% | El intervalo con mejor relación entre coste y beneficio |
| Capas de UI y vistas | 50~60% | Cambian con frecuencia y su mantenimiento de pruebas es costoso |
| Archivos generados automáticamente y de configuración | Excluir de la medición | Las pruebas aportan poco significado |
Google también ha declarado públicamente que internamente considera el 60% «aceptable», el 75% «recomendado» y el 90% «ejemplar».
No existe una respuesta única, pero puede considerar alrededor del 80% un objetivo razonable para la mayoría de los equipos.
¿Por qué insistir en el 100% puede resultar contraproducente?
El esfuerzo necesario para cubrir el último 20% es mucho mayor que el necesario para cubrir el primer 80%.
Probar todas las excepciones, ramas difíciles de alcanzar y comprobaciones defensivas hace que el tiempo crezca exponencialmente.
Hay un problema aún mayor.
Aparecen «pruebas de escaparate» creadas solo para completar la cifra.
Las pruebas que elevan la cobertura sin verificar realmente nada solo dificultan el trabajo cuando más adelante se cambia el código.
Cada refactorización acaba consumiendo tiempo en corregir pruebas sin significado.
Preguntas frecuentes (Q&A)
P. Entonces, ¿medir la cobertura no sirve para nada?
No. La cobertura es muy útil para encontrar áreas a las que las pruebas nunca llegan.
En lugar de convertir la cifra en un objetivo, úsela para revisar las zonas rojas del informe de cobertura (código no ejecutado).
P. ¿Se puede imponer un umbral de cobertura en CI?
Sí, pero recomiendo un enfoque como «el código nuevo debe tener al menos un 80%».
Imponer un umbral alto a todo el código agota al equipo debido al código existente.
P. ¿Hay varios tipos de cobertura?
Además de la cobertura de líneas, conviene revisar también la cobertura de ramas.
Comprobar si las ramas condicionales, como if/else, se han probado correctamente se acerca más a la calidad real.
No se deje perseguir por la cifra; pregúntese primero: «¿Esta prueba realmente está protegiendo algo?»
Un conjunto de pruebas sólido con una cobertura del 80% ofrece mucha más confianza que uno vacío con una cobertura del 100%. ¡Espero que hoy también escriba un buen código de pruebas!