Pruebas y calidad de código

Swift Testing: el nuevo estándar de Apple que sustituye a XCTest (resumen)

Al escribir código de pruebas durante el desarrollo de iOS, llega un momento en que XCTest empieza a resultar limitante.

4 min de lectura
Imagen de portada de Swift Testing: el nuevo estándar de Apple que sustituye a XCTest (resumen)

Al escribir código de pruebas durante el desarrollo de iOS, llega un momento en que XCTest empieza a resultar limitante.

A mí también me pasaba: nombres de funciones que empiezan por func test, aserciones verbosas como XCTAssertEqual y mensajes de error en los que cuesta detectar el problema de un vistazo.

En ese contexto, Apple presentó en la WWDC 2024 un nuevo framework llamado Swift Testing.

En resumen, Swift Testing es el nuevo estándar oficial de Apple para sustituir a XCTest. Con la macro @Test y un único #expect puedes escribir pruebas mucho más concisas, y viene integrado desde Xcode 16.

En este artículo resumo, basándome en mi experiencia práctica, qué es Swift Testing, en qué se diferencia de XCTest y si ya puedes usarlo.

¿Qué es Swift Testing?

Swift Testing es un framework de pruebas de código abierto que Apple presentó en la WWDC 2024.

Está construido aprovechando ampliamente las macros, una de las funciones más recientes de Swift.

La principal diferencia es que XCTest tiene raíces en la época de Objective-C, mientras que Swift Testing se diseñó desde cero siguiendo el estilo de Swift.

Desde Xcode 16 viene incluido de forma predeterminada, sin instalación adicional. También puedes usarlo directamente en paquetes de Swift.

El cambio más visible está en la sintaxis. Ya no es necesario que el nombre de la función de prueba empiece por test.

En su lugar, basta con añadir @Test encima de la función para convertirla en una prueba.

import Testing

@Test func Comprobar si el_total del carrito_es correcto() {
    let cart = Cart(items: [1000, 2000])
    #expect(cart.total == 3000)  // Muestra el valor real si falla
}

Como en el código anterior, basta con colocar una expresión de comparación normal dentro de #expect. No necesitas memorizar XCTAssertEqual ni XCTAssertTrue.


¿En qué se diferencia de XCTest?

He resumido en una tabla las diferencias clave que observé al migrar mi propio código. (A fecha de 2026)

Elemento XCTest Swift Testing
Declaración de pruebas Empieza por func test Macro @Test
Aserciones Varias, como XCTAssertEqual Unificadas con #expect
Mensajes de error Los valores se ven con dificultad Muestra automáticamente los valores reales
Pruebas repetidas Escribir un bucle for manualmente Compatibilidad integrada con pruebas parametrizadas
Ejecución en paralelo Limitada Ejecución paralela predeterminada

Lo que más me impresionó fueron las pruebas parametrizadas.

Al verificar varias veces la misma lógica cambiando solo los valores, antes teníamos que usar un bucle for o copiar y pegar la función.

En Swift Testing, basta con pasar una lista de argumentos a @Test para que cada caso se ejecute automáticamente.

También indica exactamente qué valores tenía el caso que falló.

¿Puedo usarlo ya?

Sí. Para un proyecto nuevo, recomiendo adoptarlo desde ahora.

Con Xcode 16 o posterior y Swift 6, prácticamente no hay configuración que hacer.

Hay algo que conviene saber: Swift Testing y XCTest pueden coexistir en el mismo proyecto.

Eso significa que no necesitas reescribir todo tu código existente de XCTest de la noche a la mañana.

Usa Swift Testing para las pruebas nuevas y migra las existentes poco a poco.

Es suficiente con migrar primero las pruebas nuevas, una a una
Es suficiente con migrar primero las pruebas nuevas, una a una

Hay que tener en cuenta las pruebas de UI. Las pruebas basadas en XCUITest que automatizan la interacción con la pantalla todavía pertenecen a XCTest.

Por ahora, la combinación práctica es Swift Testing para pruebas unitarias y XCTest para pruebas de UI.


Qué conviene saber al migrar

Veamos algunos consejos que me resultaron útiles durante una migración real.

Primero, usa init y deinit en lugar de setUp y tearDown. Swift Testing crea una instancia nueva para cada prueba.

Así se reducen mucho los errores causados por mezclar accidentalmente el estado entre pruebas.

Cuando un valor debe existir para poder continuar, usa #require en lugar de #expect.

Si la condición no se cumple, #require detiene la prueba en ese momento.

Ver la luz verde hace que @Test resulte sorprendentemente adictivo
Ver la luz verde hace que @Test resulte sorprendentemente adictivo

La función de etiquetas (Tag) también resulta útil. Permite agrupar pruebas relacionadas y ejecutarlas o filtrarlas juntas.

Para comprobar que un error se lanza correctamente, usa #expect(throws:).

Resumen

Swift Testing ya no es una función experimental recién aparecida, sino el próximo estándar que Apple está impulsando.

No hace falta cambiarlo todo de inmediato, pero si empiezas con las pruebas nuevas, te acostumbrarás enseguida a su comodidad.

Si el código de pruebas de iOS te ha resultado frustrante, te animo a migrar hoy mismo una sola prueba a @Test.

Lecturas relacionadas