Quality and craft · core

Testing with Swift Testing

The modern test framework — @Test, #expect, parameterised cases — and the judgement of what is worth testing at all.

12 min read14 min practice0/2 exercises5 recall cards

By the end you will be able to

Write tests with @Test, #expect and #require, including async and error cases
Collapse repetitive tests into one parameterised test
Apply the "would it break silently?" rule to decide what deserves a test

Guess firstAnswering before you read makes the explanation stick — even when you get it wrong.

A test fails: #expect(cart.total == 54). What does Swift Testing show you that the older XCTAssertEqual famously did not?

The shape of a modern test

import Testing
@testable import CartFeature

@Test func memberDiscountApplies() {
    let cart = CartModel(prices: [10, 20, 30], memberDiscount: 0.1)
    #expect(cart.total == 54)
}

@Test marks any function as a test — no class to subclass, no test name prefix, structs and global functions welcome.
#expect(condition) records a failure but keeps the test running, so one test can report several broken things.
#require is the hard version: it stops the test when its condition fails, and it unwraps optionals — let user = try #require(response.user) replaces the force-unwrap that would crash the whole suite.

Tests group into suites — a struct whose init runs fresh for every test, which is the setup story:

struct CartTests {
    let cart = CartModel(prices: [10, 20, 30], memberDiscount: 0.1)  // fresh per test

    @Test func totalAppliesDiscount() { #expect(cart.total == 54) }
    @Test func subtotalIgnoresDiscount() { #expect(cart.subtotal == 60) }
}

No shared mutable state between tests means no test-order coupling — the class of flakiness where the suite passes alone and fails on CI evaporates.

What is actually worth testing

The judgement that separates useful suites from theatre. Recall the architecture lesson's sorting rule — logic lives where tests can reach it. The complementary rule: test what would break silently.

Code	Test it?	Why
Discount/pricing rules	yes, thoroughly	wrong answers look plausible — nobody notices 8% vs 10% by eye
Date/timezone logic	yes	breaks twice a year, at 11pm, in another country
Parsing server responses	yes, with ugly fixtures	the sad payloads are exactly what QA never types in
A computed property returning `a + b`	briefly	cheap to test, cheap to break visibly
"The button is blue"	no	breaks loudly in any screenshot or preview
Apple's frameworks	no	you are testing your assumptions, not their code

The highest-yield tests in a real codebase are the boundary tables: empty input, one element, the exact threshold, one past it, negative, enormous. That shape has a dedicated tool:

Parameterised tests

@Test(arguments: [
    (0, "free"), (1, "free"),
    (10, "bronze"), (49, "bronze"),
    (50, "silver"), (200, "gold"),
])
func tierForPoints(points: Int, expected: String) {
    #expect(LoyaltyModel.tier(for: points) == expected)
}

One function, six independent test cases — each reported separately, each re-runnable alone. The lazy alternative (a for loop inside one test) stops at the first failure and reports one opaque red X; the parameterised version tells you "49 and 50 pass, 200 fails", which usually is the diagnosis.

The runnable model

The framework's mechanics — expectations that record rather than abort, boundary tables — run right here:

A miniature #expect + parameterised-boundary harness, exercising real tier logic.

struct LoyaltyModel {
    static func tier(for points: Int) -> String {
        if points >= 200 { return "gold" }
        if points >= 50 { return "silver" }
        if points >= 10 { return "bronze" }
        return "free"
    }
}

// #expect semantics: record the failure with values visible, keep going.
struct TestRun {
    var failures = 0

    mutating func expect(_ ok: Bool, _ label: String) {
        if !ok {
            failures += 1
            print("FAIL  \(label)")
        }
    }
}

var run = TestRun()

// The boundary table — thresholds and their neighbours:
let cases = [
    (0, "free"), (9, "free"),
    (10, "bronze"), (49, "bronze"),
    (50, "silver"), (199, "silver"),
    (200, "gold"),
]

for (points, expected) in cases {
    let actual = LoyaltyModel.tier(for: points)
    run.expect(actual == expected, "tier(for: \(points)) → \(actual), expected \(expected)")
}

print(run.failures == 0 ? "all \(cases.count) cases passed" : "\(run.failures) failing")

Change the >= 50 in the model to > 50 and re-run: exactly the (50, "silver") row fails, with both values printed. That precision — the boundary case naming its own bug — is what the table shape buys, and why "the exact threshold and one past it" belongs in every arguments list you write.

Async and errors

Tests speak the language of the code under test:

@Test func refreshPublishesQuotes() async throws {
    let model = WatchlistModel(fetcher: FixedQuotes())   // the fake from D1
    await model.refresh()
    #expect(model.portfolioTotal == 630.75)
}

@Test func withdrawingTooMuchThrows() {
    #expect(throws: BankError.insufficientFunds(shortfall: 100)) {
        try withdraw(200, from: 100)
    }
}

#expect(throws:) asserts an error is thrown and matches — the previously awkward "test the sad path" becomes one line. Every fake you built in the architecture lesson slots directly into the first shape: inject the failing fake, await, assert on the user-facing outcome. That pairing — DI providing the seam, the test exercising it — is the whole system working as designed.

Predict, then runA wrong prediction you have committed to is worth more than a right answer you read.

Suites get a fresh instance per test. This model shows why that rule exists — what does it print?

// A suite WITHOUT per-test isolation — one shared instance:
final class SharedSuite {
    var cart: [Double] = []

    func testAddOne() -> Bool {
        cart.append(10)
        return cart.count == 1
    }

    func testStartsEmpty() -> Bool {
        return cart.isEmpty
    }
}

let shared = SharedSuite()
print("A then B: \(shared.testAddOne()) \(shared.testStartsEmpty())")

let sharedReversed = SharedSuite()
print("B then A: \(sharedReversed.testStartsEmpty()) \(sharedReversed.testAddOne())")

Check yourself

Which of these is the strongest candidate for the next test you write, on the "breaks silently" rule?

›

Find the boundary bug

Write the code

The validator has an off-by-one bug against its spec. The boundary table below is the test — read the failures it prints, fix isValid, and make the table pass clean.

// SPEC: usernames are valid at 3 to 20 characters, inclusive on both ends.
func isValid(_ username: String) -> Bool {
    username.count > 3 && username.count <= 20
}

let boundaryCases: [(String, Bool)] = [
    ("ab", false),                       // below minimum
    ("abc", true),                       // exact minimum — inclusive
    ("abcd", true),
    ("abcdefghijklmnopqrst", true),      // exact maximum (20) — inclusive
    ("abcdefghijklmnopqrstu", false),    // one past maximum
]

var failures = 0
for (input, expected) in boundaryCases {
    let actual = isValid(input)
    if actual != expected {
        failures += 1
        print("FAIL \(input) (\(input.count) chars): got \(actual), expected \(expected)")
    }
}
print(failures == 0 ? "all clear" : "\(failures) failing")

Solution unlocks after 3 attempts

›

Test the sad path through a fake

Write the code

The happy path is tested; the valuable one isn't. Add a FailingGateway fake and a second check proving the model reports a payment failure without corrupting its state.

protocol PaymentGateway {
    func charge(_ amount: Double) async -> Bool
}

final class CheckoutModel {
    private(set) var status = "ready"
    private(set) var paidTotal = 0.0
    private let gateway: PaymentGateway

    init(gateway: PaymentGateway) {
        self.gateway = gateway
    }

    func pay(_ amount: Double) async {
        if await gateway.charge(amount) {
            paidTotal += amount
            status = "paid"
        } else {
            status = "payment failed — try another card"
        }
    }
}

struct AlwaysCharges: PaymentGateway {
    func charge(_ amount: Double) async -> Bool { true }
}

func main() async {
    let happy = CheckoutModel(gateway: AlwaysCharges())
    await happy.pay(49.0)
    print("\(happy.status) \(happy.paidTotal)")

    // Add: FailingGateway, and prove status changes while paidTotal stays 0.
}

await main()

Solution unlocks after 3 attempts

Design itSaved on this device. Never graded.

Take the FSRS scheduler idea from this very platform — "a card reviewed successfully gets a longer interval; a failed card gets a short one". Write the boundary table you would feed @Test(arguments:): at least six (input state, rating) → expected-behaviour rows, including the edges. Which single row, if it regressed, would damage a learner's progress silently?

Checkpoint

You can now:

Write suites with @Test, #expect, #require, async and throws variants
Turn boundary analysis into parameterised argument tables
Route sad paths through injected fakes and assert on state and message
Argue for what not to test

Next up: accessibility — correctness for the users your tests don't represent.

How well do you know this now? Rating yourself honestly, then being tested on it, is how you find out where your intuition is wrong.