Aprender a escribir unit tests en Xcode con XCTest te permite validar funciones simples y procesos asíncronos sin depender de la interfaz. Aquí verás cómo aplicar XCTAssert, expectations y un flujo real con un proyecto que consume el API de Valorant, ideal si trabajas con arquitectura MVVM en Swift.

Cómo se estructura un archivo XCTestCase en Xcode

Al crear un archivo de tipo XCTestCase, Xcode genera una escaleta básica con dos funciones que conviene entender antes de escribir cualquier prueba.

El método setUp define qué debe ocurrir antes de ejecutar cada test, útil para inicializar objetos o estados. El método tearDown se ejecuta después de cada test y sirve para limpiar lo que dejaste preparado. Cualquier función cuyo nombre empiece con la palabra test será reconocida automáticamente como un caso a ejecutar.

¿Qué es XCTestCase? Es la clase base del framework XCTest que agrupa los métodos de prueba de una unidad de código en Swift. Cada función que empieza con test se ejecuta como un caso independiente.

El proyecto de práctica está disponible en el repositorio enlazado en los recursos de la clase [01:00]. Una vez clonado y configurado, al correrlo en el simulador verás una app sencilla que lista los agentes de Valorant usando un ViewModel que hace fetch al API y actualiza la lista cuando la respuesta es exitosa.

Qué tipos de XCTAssert puedes usar para validar resultados

El framework XCTest ofrece varios asserts que cubren la mayoría de validaciones que necesitarás en tus pruebas.

Entre los más útiles están:

• XCTAssertEqual(expr1, expr2): compara dos expresiones sin importar el tipo de dato.
• XCTAssertNotEqual: valida que dos expresiones sean distintas.
• XCTAssertTrue: pasa si la expresión booleana es verdadera.
• XCTAssertThrowsError: verifica que una función lance un error.
• XCTAssertLessThanOrEqual: compara magnitudes numéricas.

Todos aceptan un parámetro final opcional con un mensaje de error personalizado, muy útil cuando otra persona del equipo necesita entender qué se esperaba que pasara [05:30].

Cómo probar una función simple con XCTAssertEqual

Imagina una función helloWorld(name:) que recibe un string y retorna "Hello, " + name + "!". Para probarla, basta con escribir:

swift XCTAssertEqual(helloWorld(name: "Alice"), "Hello, Alice!")

Si cambias un solo carácter, por ejemplo quitando el signo de admiración, Xcode te devolverá un mensaje descriptivo indicando que "Hello, Alice!" no es igual a "Hello, Alice". Ese nivel de detalle te ahorra tiempo cuando depuras pruebas que fallan.

¿Cómo corro un solo test en Xcode? Haz clic en el rombo que aparece al lado del nombre de la función. Si quieres correr todos los tests de la clase, usa el play que está al lado del nombre de la clase.

Cómo testear funciones asíncronas con expectations

No todas las funciones devuelven un valor de inmediato. Cuando trabajas con llamadas a un API, accesos a base de datos o cualquier proceso que use closures o callbacks, necesitas un mecanismo distinto: las expectations.

Una expectation le dice al test "espera hasta que algo confirme que terminó, o hasta que se cumpla un tiempo máximo". El flujo tiene tres pasos clave:

1. Crear la expectativa con XCTestExpectation(description:) y una descripción clara.
2. Llamar a la función asíncrona y, dentro de su closure de finalización, invocar expectation.fulfill().
3. Usar wait(for: [expectation], timeout: 5) para pausar la ejecución hasta que se cumpla el fulfill o se agote el timeout.

Un ejemplo concreto: una función functionWithCompletion simula una tarea que tarda dos segundos y, al terminar, cambia una variable completed de falso a verdadero antes de notificar al closure [11:00]. La prueba quedaría así:

swift func testFunctionWithCompletion() { let expectation = XCTestExpectation(description: "functionWithCompletion") self.functionWithCompletion { expectation.fulfill() } wait(for: [expectation], timeout: 5) XCTAssertTrue(completed) }

Si la función nunca llama al fulfill, el test esperará cinco segundos y luego evaluará completed, que seguirá siendo falso, y fallará. Si todo sale bien, la variable cambiará a verdadero y el XCTAssertTrue pasará.

¿Para qué sirve una expectation en XCTest? Sirve para pausar la ejecución del test hasta que un proceso asíncrono confirme que terminó, evitando que el assert se evalúe antes de tiempo.

Por qué este enfoque te prepara para testear un ViewModel real

El proyecto de Valorant usa una arquitectura MVVM donde el ViewModel hace un fetch asíncrono al API y, al recibir la respuesta, actualiza la lista de agentes que la vista muestra.

Con lo aprendido sobre XCTAssertEqual, XCTAssertTrue y expectations, ya tienes las piezas necesarias para validar tanto la lógica síncrona como las llamadas al API. La clave está en aislar el comportamiento del ViewModel, simular las respuestas y verificar que la lista de agentes quede correctamente seteada cuando el proceso termina.

¿Qué función de tu proyecto te gustaría testear primero, una síncrona o una con completion? Cuéntalo en los comentarios.