Tests parametrizados en Swift Testing: las 5 trampas que debes evitar

🚀 SwiftTesting llegó en WWDC24 con una de las funcionalidades más esperadas: los tests parametrizados. En lugar de escribir múltiples tests casi idénticos, podemos ejecutar un solo test con diferentes argumentos automáticamente.

⚠️ Sin embargo, la conveniencia de parametrizar puede llevarnos a cometer errores sutiles que comprometen la calidad de nuestras pruebas. Migrar decenas de miles de tests ha revelado patrones problemáticos que debemos evitar.

🔍 Trampa 1: Huecos en la cobertura. Cuando usamos variables opacas en las aserciones, el test puede pasar incluso con bugs reales. Si verificamos que una función devuelve el mismo valor calculado que genera, estamos duplicando la lógica en lugar de validarla.

🧩 Trampa 2: Lógica en los tests. Cuando añadimos condicionales dentro de tests parametrizados para manejar casos especiales, estamos acoplando el test a la implementación. Los tests deben verificar comportamientos, no reflejar la estructura interna del código.

📐 Trampa 3: Tests frágiles por CaseIterable. Usar .allCases con zip() crea dependencia del orden de los casos del enum. Reordenar casos alfabéticamente o añadir associated values rompe los tests sin motivo funcional, generando daño inducido por testing".

❌ Trampa 4: Casos silenciosamente ignorados. La función zip() trunca al array más corto, dejando casos sin probar. Añadir un nuevo case puede pasar desapercibido porque simplemente se descarta, creando huecos en la cobertura.

📖 Trampa 5: Pérdida de legibilidad. Extraer los argumentos a variables o funciones separadas reduce la transparencia. Lo que se prueba y lo que se espera son las ideas clave de un test y deben estar explícitas.

✅ Mejores prácticas: Usa arrays literales de tuplas o diccionarios en lugar de zip(). Define los casos directamente en @Test(arguments:) para mantener visibilidad. Para Swift 6.2+, considera InlineArray con zip tipado que garantiza longitudes iguales en tiempo de compilación.

👨‍💻 Los tests parametrizados son potentes pero requieren cuidado. No todo test debe parametrizarse. Pregúntate si estás ganando claridad o simplemente ocultando complejidad detrás de abstracciones. ¿Ya has migrado a Swift Testing en tus proyectos?