Ao escrever código de testes no desenvolvimento para iOS, chega um momento em que o XCTest começa a parecer limitado.
Eu também me sentia assim: nomes de funções começando com func test, asserções verbosas como XCTAssertEqual e mensagens de falha que não deixam o problema claro de imediato.
Foi nesse contexto que a Apple anunciou, na WWDC 2024, um novo framework chamado Swift Testing.
Indo direto ao ponto, Swift Testing é o novo padrão oficial da Apple para substituir o XCTest. Com a macro @Test e um único #expect, você escreve testes muito mais enxutos, e ele vem integrado desde o Xcode 16.
Neste artigo, vou explicar o que é o Swift Testing, como ele difere do XCTest e se já vale a pena usá-lo, com base na minha experiência prática.
O que é Swift Testing?
Swift Testing é um framework de testes de código aberto apresentado pela Apple na WWDC 2024.
Ele foi criado aproveitando bastante as macros, um dos recursos mais recentes da linguagem Swift.
A maior diferença é que, enquanto o XCTest tem raízes na época do Objective-C, o Swift Testing foi projetado desde o início de acordo com o estilo do Swift.
A partir do Xcode 16, ele já vem incluído por padrão, sem instalação separada. Também pode ser usado diretamente em pacotes Swift.
A mudança mais evidente está na sintaxe. O nome da função de teste não precisa mais começar com test.
Em vez disso, basta adicionar @Test acima da função para transformá-la em um teste.
import Testing
@Test func Verificar se o_total do carrinho_está correto() {
let cart = Cart(items: [1000, 2000])
#expect(cart.total == 3000) // Mostra o valor real quando falha
}Como no código acima, basta colocar uma expressão de comparação comum dentro de #expect. Você não precisa decorar XCTAssertEqual e XCTAssertTrue.
Qual é a diferença em relação ao XCTest?
Resumi em uma tabela as principais diferenças que percebi ao migrar meu próprio código. (Em 2026)
| Item | XCTest | Swift Testing |
|---|---|---|
| Declaração do teste | Começa com func test | Macro @Test |
| Asserções | Várias, como XCTAssertEqual | Unificadas em #expect |
| Mensagens de falha | Os valores não ficam claros | Exibe os valores reais automaticamente |
| Testes repetidos | Escrever um loop for manualmente | Suporte integrado a testes parametrizados |
| Execução paralela | Limitada | Execução paralela por padrão |
O que mais me impressionou foram os testes parametrizados.
Ao verificar várias vezes a mesma lógica mudando apenas os valores, antes precisávamos executar um loop for ou copiar e colar a função.
No Swift Testing, basta passar uma lista de argumentos para @Test para que cada caso seja executado automaticamente.
Ele também mostra exatamente quais valores estavam no caso que falhou.
Já posso usar agora?
Sim. Em um projeto novo, recomendo adotá-lo imediatamente.
Com Xcode 16 ou posterior e Swift 6, praticamente não há configuração para fazer.
Há um ponto importante: Swift Testing e XCTest podem coexistir no mesmo projeto.
Isso significa que você não precisa reescrever todo o código XCTest existente de uma hora para outra.
Use Swift Testing nos testes novos e migre os antigos aos poucos.
Um cuidado é com os testes de UI. Os testes baseados em XCUITest que automatizam a interação com a tela ainda fazem parte do XCTest.
Por enquanto, a combinação mais prática é Swift Testing para testes unitários e XCTest para testes de UI.
O que você deve saber ao migrar
Vou destacar algumas dicas que foram úteis durante uma migração real.
Primeiro, use init e deinit em vez de setUp e tearDown. O Swift Testing cria uma nova instância para cada teste.
Assim, os erros causados pela mistura de estado entre testes diminuem bastante.
Quando um valor precisa existir para avançar para a próxima etapa, use #require em vez de #expect.
Se a condição não for atendida, #require interrompe o teste naquele momento.
O recurso de tags (Tag) também é útil. Você pode agrupar testes relacionados e executá-los ou filtrá-los de uma vez.
Para verificar se um erro é lançado corretamente, use #expect(throws:).
Resumo
Swift Testing já não é um recurso experimental recém-lançado; é o próximo padrão promovido pela Apple.
Você não precisa mudar tudo imediatamente, mas, começando pelos testes novos, logo se acostumará com a praticidade.
Se o código de testes do iOS tem deixado você frustrado, recomendo migrar hoje mesmo apenas um teste para @Test.