Testbare Architektur

Das Problem: Code, der sich nicht testen lässt

In Lektion 4.10 hast du gelernt, Tests zu schreiben. Jetzt willst du die Monatssumme aus Projekt E testen. Sie steht so im Code:

struct ExpenseList: View {
    @Query private var expenses: [Expense]

    private var monthTotal: Double {
        expenses
            .filter { Calendar.current.isDate($0.date, equalTo: .now, toGranularity: .month) }
            .reduce(0) { $0 + $1.amount }
    }

    var body: some View { ... }
}

Wie testest du das?

• Die Berechnung ist eine private Eigenschaft einer View. Von außen kommst du nicht heran.
• Sie liest @Query, braucht also eine Datenbank und eine laufende View.
• Sie verwendet .now: Heute ergibt sie etwas anderes als nächsten Monat. Ein Test, der heute grün ist, kann morgen rot sein.
• Sie verwendet Calendar.current: Auf einem Rechner in Tokio fällt Mitternacht woanders hin als in Wien.

Der Code funktioniert, aber er ist nicht testbar. Das ist kein Problem der Tests, sondern der Architektur: wie der Code aufgeteilt ist. Diese Lektion zeigt die Handgriffe, mit denen fast jeder Code testbar wird. Sie machen ihn nebenbei auch übersichtlicher.

Grundsatz 1: Logik raus aus der View

Eine View sollte beschreiben, wie etwas aussieht. Berechnungen, Regeln und Entscheidungen gehören woandershin, wo sie ohne Bildschirm laufen können.

Reine Funktionen

Der beste Ort für Logik ist eine reine Funktion: Sie bekommt alles, was sie braucht, als Parameter und liefert ein Ergebnis. Sie liest nichts von außen und verändert nichts.

enum ExpenseMath {
    static func total(
        of expenses: [(date: Date, amount: Double)],
        inMonthOf reference: Date,
        calendar: Calendar
    ) -> Double {
        expenses
            .filter { calendar.isDate($0.date, equalTo: reference, toGranularity: .month) }
            .reduce(0) { $0 + $1.amount }
    }
}

Die View ruft sie nur noch auf:

private var monthTotal: Double {
    ExpenseMath.total(
        of: expenses.map { ($0.date, $0.amount) },
        inMonthOf: .now,
        calendar: .current
    )
}

Und der Test kann alles festlegen:

@Test("Ausgabe um 23:59 gehört noch zum alten Monat")
func lastMinuteOfMonth() throws {
    var calendar = Calendar(identifier: .gregorian)
    calendar.timeZone = try #require(TimeZone(identifier: "Europe/Vienna"))

    let lastMinute = try #require(calendar.date(from: DateComponents(year: 2026, month: 9, day: 30, hour: 23, minute: 59)))
    let firstMinute = try #require(calendar.date(from: DateComponents(year: 2026, month: 10, day: 1, hour: 0, minute: 0)))
    let reference = try #require(calendar.date(from: DateComponents(year: 2026, month: 10, day: 15)))

    let total = ExpenseMath.total(
        of: [(lastMinute, 10), (firstMinute, 20)],
        inMonthOf: reference,
        calendar: calendar
    )

    #expect(total == 20)
}

Fester Kalender, feste Zeitzone, feste Daten. Der Test läuft heute, in einem Jahr und auf jedem Rechner der Welt gleich.

Woran du nicht testbaren Code erkennst

Achte beim Schreiben auf diese Warnzeichen. Jedes macht Tests schwer:

Das Muster ist immer dasselbe: Was von außen kommt, wird übergeben, statt es sich selbst zu holen.

Grundsatz 2: Abhängigkeiten austauschbar machen

Nicht alles lässt sich in reine Funktionen verwandeln. Ein ViewModel, das Rezepte lädt, muss irgendwann das Netzwerk benutzen. Wie testest du es, ohne bei jedem Testlauf echte Anfragen an TheMealDB zu schicken?

Das Problem

@Observable
class MealListModel {
    var state: LoadState<[Meal]> = .idle
    private let api = MealAPI()                  // ⚠️ fest verdrahtet

    func load(category: String) async {
        state = .loading
        do {
            state = .loaded(try await api.meals(in: category))
        } catch {
            state = .failed("Laden fehlgeschlagen")
        }
    }
}

Das Modell erzeugt seine API selbst. Ein Test würde echte Netzwerkaufrufe machen: langsam, abhängig vom Server und ohne Möglichkeit, einen Fehler gezielt auszulösen.

Die Lösung: ein Protokoll

Zuerst beschreibst du, was das Modell vom Netzwerk braucht, in einem Protokoll (Lektion 1.15):

protocol MealService: Sendable {
    func meals(in category: String) async throws -> [Meal]
}

Die echte API erfüllt es:

extension MealAPI: MealService {}

Das Modell bekommt seinen Dienst von außen:

@Observable
class MealListModel {
    var state: LoadState<[Meal]> = .idle
    private let service: any MealService

    init(service: any MealService = MealAPI()) {
        self.service = service
    }

    func load(category: String) async {
        state = .loading
        do {
            state = .loaded(try await service.meals(in: category))
        } catch {
            state = .failed("Laden fehlgeschlagen")
        }
    }
}

Der Standardwert = MealAPI() sorgt dafür, dass sich in der App nichts ändert: MealListModel() funktioniert wie vorher.

Testdoubles

Im Test übergibst du einen Ersatz, ein sogenanntes Testdouble, das sich genau so verhält, wie der Test es braucht:

struct StubMealService: MealService {
    var result: Result<[Meal], Error>

    func meals(in category: String) async throws -> [Meal] {
        try result.get()
    }
}

Result ist ein Enum mit den Fällen .success(Wert) und .failure(Fehler). result.get() gibt den Wert zurück oder wirft den Fehler.

Jetzt kannst du beide Wege testen, ohne Netzwerk, in Millisekunden:

@MainActor
@Suite("Rezeptliste")
struct MealListModelTests {
    let sample = [Meal(id: "1", name: "Pfannkuchen", thumbnail: nil)]

    @Test("Erfolgreiches Laden zeigt die Rezepte")
    func loadSuccess() async {
        let model = MealListModel(service: StubMealService(result: .success(sample)))
        await model.load(category: "Dessert")
        #expect(model.state == .loaded(sample))
    }

    @Test("Fehler beim Laden zeigt eine Meldung")
    func loadFailure() async {
        let model = MealListModel(service: StubMealService(result: .failure(URLError(.notConnectedToInternet))))
        await model.load(category: "Dessert")
        #expect(model.state == .failed("Laden fehlgeschlagen"))
    }
}

Damit == funktioniert, müssen LoadState und Meal Equatable sein. Bei Enums mit Equatable-Werten reicht dafür : Equatable hinter dem Namen.

Ein Spy

Manchmal willst du prüfen, ob und wie eine Abhängigkeit aufgerufen wurde:

final class SpyMealService: MealService, @unchecked Sendable {
    private(set) var requestedCategories: [String] = []

    func meals(in category: String) async throws -> [Meal] {
        requestedCategories.append(category)
        return []
    }
}

@Test("Lädt die gewählte Kategorie")
func requestsCategory() async {
    let spy = SpyMealService()
    let model = MealListModel(service: spy)
    await model.load(category: "Seafood")
    #expect(spy.requestedCategories == ["Seafood"])
}

@unchecked Sendable verspricht dem Compiler, dass der Spy sicher zwischen Threads verwendet werden darf, ohne dass er es prüfen kann. Für einen Test, der nacheinander abläuft, ist das in Ordnung. In App-Code solltest du so ein Versprechen nur mit gutem Grund geben (Lektion 3.8).

Grundsatz 3: SwiftData-Logik testen

Logik, die direkt mit SwiftData arbeitet, testest du mit einem Container im Arbeitsspeicher, so wie der previewContainer aus Lektion 3.14:

@MainActor
@Suite("Kategorien")
struct CategoryTests {
    let context: ModelContext

    init() throws {
        let container = try ModelContainer(
            for: Expense.self, Category.self,
            configurations: ModelConfiguration(isStoredInMemoryOnly: true)
        )
        context = container.mainContext
    }

    @Test("Löschen einer Kategorie behält die Ausgaben")
    func deleteKeepsExpenses() throws {
        let food = Category(name: "Essen", icon: "fork.knife", tint: .orange)
        let lunch = Expense(title: "Mittag", amount: 12, category: food)
        context.insert(lunch)

        context.delete(food)
        try context.save()

        let remaining = try context.fetch(FetchDescriptor<Expense>())
        #expect(remaining.count == 1)
        #expect(remaining.first?.category == nil)
    }
}

Jeder Test bekommt einen eigenen, leeren Container, weil der Initializer für jeden Test neu läuft. Tests können sich nicht gegenseitig stören, und nichts landet auf der Festplatte.

Dieser Test prüft übrigens die Löschregel .nullify aus Projekt E. Ändert jemand sie versehentlich in .cascade, schlägt er sofort fehl, bevor ein Nutzer seine Ausgaben verliert.

Wie viel Architektur?

Es ist leicht, es zu übertreiben: Protokolle für alles, fünf Schichten für einen Bildschirm, Fabriken für Fabriken. Das macht Code nicht testbarer, sondern nur schwerer zu lesen.

Eine pragmatische Faustregel:

• Reine Logik (Berechnungen, Regeln, Parsing): immer in Funktionen oder Werttypen auslagern. Kostet fast nichts.
• Externe Dienste (Netzwerk, Dateien, Systemfunktionen wie Benachrichtigungen): hinter ein kleines Protokoll stellen, sobald du das Modell testen willst.
• SwiftData: direkt verwenden und mit Containern im Arbeitsspeicher testen. Ein eigenes Protokoll darüber lohnt sich selten.
• Views: nicht in Unit-Tests prüfen. Was eine View anzeigt, prüfst du mit Previews und, für wichtige Abläufe, mit UI-Tests (Lektion 4.12).

Typische Fehler

Tests schlagen „manchmal“ fehl

Der Code verwendet Date.now, Calendar.current, Zufall oder gemeinsamen Zustand. Mach diese Abhängigkeiten zu Parametern.

Tests sind langsam und brauchen Internet

Echte Netzwerkaufrufe in Unit-Tests. Ersetze den Dienst durch einen Stub.

Logik ist in der View versteckt

Private berechnete Eigenschaften in Views sind nicht testbar. Zieh die Logik in eine Funktion oder ein Modell, das die View nur aufruft.

Zu viele Protokolle

Ein Protokoll für jede Klasse, auch wenn es nur eine Umsetzung gibt und nie ersetzt wird. Führe Protokolle erst ein, wenn du wirklich austauschen willst, meist für Tests externer Dienste.

FAQ

Übungen

// Im Modell
func load(category: String) async {
    state = .loading
    do {
        state = .loaded(try await service.meals(in: category))
    } catch let error as URLError where error.code == .notConnectedToInternet {
        state = .failed("Keine Internetverbindung")
    } catch {
        state = .failed("Laden fehlgeschlagen")
    }
}

// Test
@MainActor
@Test("Fehlermeldungen", arguments: [
    (URLError(.notConnectedToInternet) as any Error, "Keine Internetverbindung"),
    (URLError(.timedOut) as any Error, "Laden fehlgeschlagen"),
    (CocoaError(.fileReadCorruptFile) as any Error, "Laden fehlgeschlagen")
])
func errorMessages(error: any Error, message: String) async {
    let model = MealListModel(service: StubMealService(result: .failure(error)))
    await model.load(category: "Dessert")
    #expect(model.state == .failed(message))
}

Zusammenfassung

• Testbarkeit ist eine Frage der Architektur: wie der Code aufgeteilt ist.
• Logik raus aus der View, am besten in reine Funktionen, die alles als Parameter bekommen.
• Was von außen kommt, wird übergeben: Datum, Kalender, Zufall, Speicher, Dienste. Mit Standardwerten bleibt der Aufruf in der App kurz.
• Externe Dienste hinter ein kleines Protokoll. Im Test ersetzen Stubs, Fakes und Spies die echten Dienste.
• SwiftData-Logik mit einem Container im Arbeitsspeicher testen, für jeden Test frisch.
• Nicht übertreiben: Protokolle nur dort, wo du wirklich austauschen willst.

Spickzettel

// reine Funktion mit Standardwerten
static func total(of items: [Item], in month: Date = .now, calendar: Calendar = .current) -> Double

// Dienst hinter Protokoll
protocol MealService: Sendable {
    func meals(in category: String) async throws -> [Meal]
}
extension MealAPI: MealService {}

@Observable class Model {
    private let service: any MealService
    init(service: any MealService = MealAPI()) { self.service = service }
}

// Stub im Test
struct Stub: MealService {
    var result: Result<[Meal], Error>
    func meals(in category: String) async throws -> [Meal] { try result.get() }
}

// SwiftData im Test
let container = try ModelContainer(for: Item.self,
    configurations: ModelConfiguration(isStoredInMemoryOnly: true))