[SC] Probando código concurrente con XCTest

Comprensión durante la lectura

¿Por qué es difícil escribir tests para código asíncrono?

Si las pruebas para código asíncrono no están bien hechas, puede ser que funcionen por coincidencia, dando la falsa idea de que el código es seguro.

¿Qué son los "flaky tests" y cómo se pueden evitar?

Un "flaky test" es una prueba que funciona algunas veces, y otras no.

¿Qué desafíos introduce @MainActor al momento de hacer tests?

Si una clase o método de producción está aislado en MainActor, la prueba (o clase de prueba) puede hacer await para hacer el cambio de dominio de aislamiento, o también puede ser marcada con @MainActor. No obstante, esto último implicaría que las pruebas (o clase de prueba) marcadas con @MainActor se ejecutan de forma serial.

Ante esta problemática, se recomienda extraer el comportamiento en otra clase que no esté marcada con @MainActor.

¿Cómo se puede esperar a que una tarea asíncrona complete dentro de un test?

Un método async puede esperarse con await directamente, y poniendo async en la firma de la prueba.

¿Por qué no se puede usar wait(for:) en contextos de concurrencia?

Los métodos normales para esperar por un XCTExpectation no están diseñados para trabajar en un ambiente concurrente. Por esta razón, se debe usar en su lugar fulfillment(of:timeout:enforceOrder:).

¿Qué es el "System Under Test" (SUT)?

"SUT" es una convención de nombre para referirse a la clase que va a ser probada.

¿Por qué falla el test con searchWithSearchTask aunque el código se vea correcto?

Internamente tiene un try await Task.sleep(for: .milliseconds(500)). Como inicialmente se construyó la prueba como si fuera síncrona, esto no daba tiempo al código de producción para ejecutar el sleep y terminar adecuadamente.

Recordar sin releer

¿Cómo se usa withObservationTracking para resolver el problema de esperar resultados?

1. Se crea un XCTExpectation. Por ejemplo: let expectation = self.expectation(description: "\"Search complete\")"

2. Se monitorean cambios en una variable de una clase marcada con @Observable, o que sea @Published, con el bloque withObservationTracking(_:onChange:). El objetivo es que, ante cualquier cambio de la variable de interés, se haga fulfill() sobre el XCTestExpectation.

3. Se espera al fulfill() del XCTExpectation con fulfillment(of:timeout:enforceOrder:).

4. Se hacen las validaciones que sean necesarias con XCTAssert.

¿Cómo se declaran setUp y tearDown para soportar código asíncrono?

• func setUp() async throws
• func tearDown() async throws

Revisión y síntesis

¿Cuáles son las tres técnicas clave aprendidas para testear código concurrente?

¿En qué situaciones usarías @MainActor en un test y cuál es su costo?

¿Qué diferencia hay entre este enfoque y el que ofrece el framework Swift Testing mencionado al final?

Bibliografía

• Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.