Tests en CI: paralelizar, simuladores y tests inestables

Una suite que en tu máquina tarda seis minutos y en integración continua tarda treinta y cinco no tiene un problema de máquina: tiene un problema de diseño de ejecución. Y una suite que falla al azar una vez de cada veinte ejecuciones no tiene un problema de pruebas: tiene un problema de gobierno, porque en cuanto el equipo aprende que el rojo puede no significar nada, todas las pruebas de la suite pierden su capacidad de detener un cambio malo, incluidas las buenas. Los dos asuntos de esta lección —tiempo de ciclo e inestabilidad— son en realidad el mismo asunto visto desde dos lados: qué hace falta para que el resultado de la suite sea una señal en la que alguien esté dispuesto a basar una decisión.

El tiempo de ciclo es el requisito, no el resultado

La primera decisión no es técnica sino de producto: cuánto tiempo puede transcurrir entre subir un cambio y saber si rompió algo. Diez minutos es el umbral por debajo del cual la gente espera el resultado; por encima de veinte, cambia de tarea y el coste del contexto perdido se suma a cada iteración. Ese número se fija primero y luego se diseña la ejecución para cumplirlo, no al revés.

La herramienta que lo hace posible son los planes de prueba, porque permiten que el mismo proyecto tenga varias suites con propósitos distintos y configuraciones distintas.

# En cada propuesta de cambio: rapido, determinista, sin interfaz.
xcodebuild test \
  -scheme MiApp \
  -testPlan Rapido \
  -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' \
  -parallel-testing-enabled YES \
  -maximum-parallel-testing-workers 4 \
  -resultBundlePath resultados.xcresult

# De noche o antes de publicar: recorridos completos e instantaneas.
xcodebuild test -scheme MiApp -testPlan Completo -destination ... -enableCodeCoverage YES

El reparto habitual usa tres planes. Uno rápido con toda la lógica y ninguna dependencia de simulador gráfico, que debe terminar en un par de minutos y se ejecuta en cada envío. Uno de fusión que añade instantáneas y pruebas de integración, ejecutado antes de incorporar el cambio a la rama principal. Y uno completo con los recorridos de extremo a extremo y las variantes de idioma y dispositivo, ejecutado por la noche o antes de una entrega, donde media hora ya no molesta a nadie. La ganancia no viene de ejecutar menos pruebas sino de ejecutarlas cuando su coste es asumible.

Paralelizar en dos ejes

Hay dos formas de paralelizar y conviene no confundirlas, porque resuelven problemas distintos y se combinan.

# Particion 2 de 4, sobre un producto ya compilado.
xcodebuild test-without-building \
  -xctestrun MiApp_iphonesimulator18.2.xctestrun \
  -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' \
  -only-testing:MiAppTests/CarritoTests \
  -only-testing:MiAppTests/DescuentosTests \
  -resultBundlePath particion2.xcresult

El paralelismo tiene un límite que casi nadie mide antes de chocar con él: cada clon de simulador consume memoria y núcleos, y pasado cierto punto los procesos compiten, los tiempos de espera se agotan por falta de recursos y aparecen fallos que no existen en ejecución secuencial. La regla práctica es subir el número de trabajadores de dos en dos y quedarse un escalón por debajo del punto donde empiezan a aparecer fallos nuevos. Un paralelismo agresivo que introduce inestabilidad es una pérdida neta, porque cada reejecución cuesta más de lo que ahorró el reparto.

El simulador merece además su propia disciplina. Fijar una versión de sistema y un modelo concretos, partir de un dispositivo recién arrancado y con datos borrados, desactivar animaciones y ajustar el modo de conectividad para que las pruebas no dependan de la red del edificio elimina una clase entera de fallos que se atribuyen erróneamente al código.

# Higiene del simulador antes de cada ejecucion en el agente.
xcrun simctl shutdown all
xcrun simctl erase all
xcrun simctl boot 'iPhone 16'
xcrun simctl bootstatus 'iPhone 16' -b        # esperar a que termine de arrancar

Ese último comando es más importante de lo que parece: lanzar pruebas contra un simulador que aún está arrancando produce fallos de tiempo agotado en el primer caso de cada ejecución, que es exactamente el patrón que después se describe como inestabilidad misteriosa. Conviene también anclar la versión de las herramientas de línea de comandos en el agente, porque un cambio de versión de Xcode altera a la vez el compilador, el simulador y el suavizado de texto, y con él se mueven las instantáneas y los tiempos.

La inestabilidad es una política, no un misterio

Una prueba inestable es la que produce resultados distintos sin que el código haya cambiado. Su daño no es proporcional a su número: una sola basta para instalar en el equipo el hábito de reejecutar ante el rojo, y ese hábito anula el valor de todas las demás. Por eso el primer paso no es arreglarla sino medirla: sin una tasa de fallo por prueba, la discusión se vuelve una colección de anécdotas.

flowchart TB
r[La suite se pone roja] --> q[Falla siempre al repetir]
q --> si[Es un defecto real: arreglar el codigo]
q --> no[Falla a veces: es inestable]
no --> m[Registrar la tasa de fallo por prueba]
m --> c[Cuarentena fuera del camino critico]
c --> d[Diagnosticar la causa]
d --> t[Tiempo: espera fija o carrera]
d --> e[Estado compartido entre pruebas]
d --> x[Recurso externo o red real]
t --> f[Arreglar y devolver al plan rapido]
e --> f
x --> f
c --> b[Sin arreglo en dos semanas: borrar la prueba]

La cuarentena tiene que ser un mecanismo explícito y con caducidad, no una etiqueta que dure para siempre. El marco moderno permite marcar una prueba con un rasgo que la desactiva dejando anotado el motivo y el asunto que la rastrea, y también admite envolver una comprobación que se sabe defectuosa para que su fallo no rompa la ejecución pero sí avise cuando deje de fallar.

@Test(.disabled("Inestable por carrera en la carga: ticket APP-482"))
func sincronizaAlVolverDeSegundoPlano() async { }

@Test func exportaElInformeMensual() async throws {
    try await withKnownIssue("Falla en agentes lentos: ticket APP-517") {
        try await sut.exportar()
    }
}

Medir es barato y casi nadie lo hace. Basta con ejecutar la suite repetidamente en la máquina de integración, con reejecución activada, y recoger del paquete de resultados qué pruebas necesitaron un segundo intento.

# Instrumento de medida: ejecutar dos veces cada caso y anotar quien pasa a la segunda.
xcodebuild test -scheme MiApp -testPlan Rapido -destination ... \
  -retry-tests-on-failure -test-iterations 2 \
  -resultBundlePath medicion.xcresult

# Extraer el detalle para construir la tabla de tasa de fallo por prueba.
xcrun xcresulttool get test-results tests --path medicion.xcresult --format json

Con treinta ejecuciones nocturnas y esa extracción tienes una tabla ordenada por tasa de fallo, que es el único documento capaz de cerrar la discusión sobre si el problema es la máquina, la prueba o el código. Guardar además la duración de cada caso alimenta el reparto equilibrado de particiones de la sección anterior, de modo que la misma medición sirve para las dos decisiones.

La reejecución automática ante fallo es útil como instrumento de medida y peligrosa como remedio permanente. Ejecutar cada prueba dos veces y marcar como inestable la que pasa en el segundo intento da exactamente el dato que hace falta; dejar esa opción activada para que la rama principal se vea verde convierte la inestabilidad en invisible y garantiza que crezca. La política que sostiene la confianza cabe en tres frases: en la rama principal no se reejecuta, una prueba inestable sale del camino crítico el mismo día con un ticket asociado, y si en dos semanas nadie la arregló se borra. Borrar una prueba que nadie confía en arreglar no destruye ninguna garantía, porque esa garantía ya no existía; lo único que destruye es la ilusión de tenerla.