ES
RU
EN
ZH
FR
DE
PT
AR
HI
Cobertura de código con pruebas en Swift: de «solo pruebas» a la confianza real
¿Alguna vez eliminó código «muerto» y una semana después falló la compilación? ¿O se enorgulleció de un 90% de cobertura, pero los errores seguían apareciendo en producción? Si es así, este artículo es para usted. La cobertura de código con pruebas (code coverage) en Swift no es solo una casilla de verificación para CI/CD. Es su radar personal: muestra qué partes del código se prueban realmente y cuáles viven «de palabra».
No hablaremos de que hay que escribir pruebas, eso es obvio. En cambio, analizaremos: cómo hacer que Xcode calcule la cobertura correctamente, qué métricas son realmente importantes (spoiler: no solo el porcentaje) y por qué el 100% de cobertura suele ser una trampa. ¡Allá vamos!
1. ¿Por qué medir la cobertura de código en Swift?
Imagínese que es el capitán de un barco y las pruebas son sus navegantes. La cobertura de código es un mapa donde se marcan las áreas «exploradas». Si el mapa está en blanco, navega a ciegas. Si está 100% coloreado, pero sin tener en cuenta los casos límite, igual corre el riesgo de encallar.
Razones principales para implementar code coverage Swift:
- Búsqueda de «zonas grises» — ve inmediatamente qué código nunca se ejecuta en las pruebas (por ejemplo, manejadores de errores).
- Refactorización sin miedo — una alta métrica de cobertura da luz verde para reescribir módulos.
- Documentación de requisitos — las pruebas se convierten en documentación viva, y la cobertura muestra qué tan completa es esa documentación.
- Control de calidad en CI — se puede prohibir el merge si la cobertura cae por debajo de un umbral (por ejemplo, 80%).
Pero recuerde lo principal: la cobertura de código con pruebas en Swift es una métrica, no un objetivo. Perseguir un número por el número mismo es el camino hacia pruebas inútiles que verifican getters y setters.
2. Herramientas para medir la cobertura en Swift: desde Xcode hasta utilidades de terceros
El ecosistema Swift ofrece varias formas de obtener los codiciados porcentajes. Analicemos tres principales: Xcode integrado, la utilidad slather y servicios de CI (por ejemplo, Codecov).
2.1. Xcode Code Coverage integrado
La herramienta más simple y accesible. Todo lo que necesita es activar la opción Gather coverage data en el esquema de compilación (Product → Scheme → Edit Scheme → Test → Options). Después de ejecutar las pruebas, abra el Report Navigator (Cmd+9) y seleccione la pestaña Coverage.
Ventajas: no requiere instalación, integración con Xcode, muestra la cobertura en tiempo real.
Desventajas: no puede combinar resultados de múltiples targets, difícil de exportar a CI.
Ejemplo de configuración para un proyecto:
// En el esquema de compilación (Test → Options) marque "Code Coverage"// Después de ejecutar las pruebas (Cmd+U) vea el informe en Report Navigator.// Para cada archivo vea una línea con el porcentaje de cobertura y las líneas resaltadas:// verdes — ejecutadas, rojas — no ejecutadas.2.2. Slather — generador de informes flexible
Slather es una utilidad open-source que analiza archivos .profdata (resultados de cobertura de Xcode) y genera informes HTML atractivos, XML (Cobertura) o incluso JSON. Es especialmente útil si usa CI y desea mantener un historial de cobertura.
Instalación a través de CocoaPods o Homebrew:
# Homebrewbrew install slather
# CocoaPods (en Podfile)pod 'slather'Ejemplo de configuración de .slather.yml:
# .slather.ymlcoverage_service: cobertura_xmlxcodeproj: MyApp.xcodeprojscheme: MyAppsource_directory: MyApp/Sourcesoutput_directory: reportsignore: - MyAppTests/* - Pods/*Ejecución:
slather coverage -s --scheme MyApp MyApp.xcodeprojVentajas: flexibilidad, soporte para diferentes formatos, integración con CI.
Desventajas:
