How to test code in Swift using actor

Igor Custodio — Thu, 12 Jun 2025 11:30:00 +0000

Hey there, today I want to talk about unit testing on iOS and I'd like to start by discussing a different way to approach changes tracking in tests.

Recently, I ran into an issue while using Swift Testing where I didn't know how to wait for a state change. In XCTest, we would use expectations to track changes and validate scenarios.

While searching online, I found the confirmation function, which helps us track value changes. It works, but honestly, I found it a bit verbose - especially since it requires a completion block and nesting logic inside it. Swift Testing provides the confirmation function to help us deal with async flows, but it still feels very "XCTest-style" with manual fulfillment. Okay, it works and we can use it for sure.

But, what about a different and simpler approach?

Let me introduce you to actors and how they can help us in this scenario.

Why Actors are great for tracking state changes

From the documentation:
"By default, actors execute tasks on a shared global concurrency thread pool. This pool is shared by all default actors and tasks, unless an actor or task specified a more specific executor requirement."

And how is it useful for us?

We can leverage the concurrency features to wait for state changes in our code and then expect the values to be properly updated in a convenient way.

Let's see it in action:

Practical example

Consider the following View Model:

struct ViewModel {
    var onOpenURL: (URL) async -> Void

    func didTap(_ url: URL) async {
        await onOpenURL(url)
    }
}

Once we call didTap passing a URL, we will call the onOpenUrl variable function to simulate a browser opening or any other asynchronous task.

In terms of testing, if we need to validate whether the URL was properly opened, we would use any confirmation or expectation to be able to validate it after the action. It would look like it for XCTest and Swift Testing.

In XCTest, we would have:

// Traditional XCTest-style test with expectation
func testOpenURL_withXCTestExpectation() async {
    let expectation = expectation(description: "URL opened")
    var recordedURL: String?

    let url = URL(string: "https://example.com")!
    let viewModel = ViewModel(onOpenURL: { url in
        recordedURL = url.absoluteString
        expectation.fulfill()
    })

    await viewModel.didTap(url)
    await fulfillment(of: [expectation])

    XCTAssertEqual(recordedURL, url.absoluteString)
}

And, in Swift Testing:

@Test
func openURL_usingConfirmation() async {
    await confirmation() { c in
        var receivedUrl: String?

        let viewModel = ViewModel(onOpenURL: { url in
            receivedUrl = url.absoluteString
            c.confirm()
        })

        let url = URL(string: "https://example.com")!
        await viewModel.didTap(url)

        #expect(receivedUrl == url.absoluteString)
    }
}

Now, let's jump into Actors and their superpowers. We still want to track the URL change inside the ViewModel and we can achieve it by using an Actor:

Declare a new test and call the record function from the Actor where you would use expectation/confirmation instead.

actor URLTracker {
    private(set) var urlString: String?

    func record(_ url: URL) {
        urlString = url.absoluteString
    }
}

Declare a new test and call the record function from the Actor where you would use expectation/confirmation instead.

@Test
func openURL_withActor() async {
    let tracker = URLTracker()
    let url = URL(string: "https://example.com")!

    let viewModel = ViewModel(onOpenURL: { url in
        await tracker.record(url)
    })

    await viewModel.didTap(url)

    let recorded = await tracker.urlString
    #expect(recorded == url.absoluteString)
}

And it's done!

This approach makes tests cleaner, easier to read, and more aligned with Swift's modern concurrency model.

Have you already used Actors for testing? Let me know in the comments!

Introdução ao desenvolvimento de layouts em iOS

Igor Custodio — Fri, 12 Nov 2021 17:29:13 +0000

Olá, mundo!

Dizem que para começar uma nova linguagem de programação você sempre precisa imprimir o "olá, mundo!" para ser bom nessa linguagem. Então, esse é o meu olá mundo de posts aqui na plataforma e na comunidade de iOS como um todo.

O foco dos meus posts vai ser em português para difundir ainda mais o assunto aqui no Brasil.

Essa semana eu fiz uma apresentação onde trabalho sobre as diferentes formas que temos para criar layouts em iOS. Podemos fazer através de:

Storyboards
XIBs
ViewCode
SwiftUI

Vale notar que Storyboards, XIBs e ViewCode utilizam AutoLayout para construir as telas (fazem uso de constraints para tal) e SwiftUI é uma outra forma diferente construir telas.

Storyboards

Aqui tem um exemplo de como é a Storyboard no Xcode

XIBs

Aqui tem um exemplo de como é a XIB no Xcode, note que é bem semelhante ao Storyboard

ViewCode

As Storyboards e XIBs são, na verdade, arquivos XML gigantes com várias definições e atributos, mas que quando abertos no Xcode são "convertidos" para uma interface amigável.

Diferente desses dois tipos de criação de tela, o outro que temos é o ViewCode, ele recebe esse nome pois não precisamos utilizar nenhuma referência visual da tela. Os desenvolvedores devem escrever todo o código da tela em Swift, tal qual como o exemplo abaixo.

SwiftUI

Para o SwiftUI acrescentei um ponto negativo temporário que que se dá por conta da tecnologia ser nova e ainda existir diversos iPhones antigos sem suporte ao iOS 13 ou um mais recente. Como a tendência desse cenário é cada vez menor, eu considero esse um ponto negativo temporário.

SwiftUI possui uma sintaxe bem mais simples na hora da criação das telas além de contar com um recurso de Preview que renderiza a tela em "tempo real".

Por hoje é isso pessoal, mas aproveito e deixo aqui um link para um guia bem introdutório ao mundo iOS com alguns recursos que acho interessante para quem está começando.

Guia sobre desenvolvimento no mundo iOS

DEV Community: Igor Custodio