swift-protocol-di-testing

Swift Protokollbasierte Abhängigkeitsinjektion für Tests

Patterns, um Swift-Code testbar zu machen, indem externe Abhängigkeiten (Dateisystem, Netzwerk, iCloud) hinter kleinen, fokussierten Protokollen abstrahiert werden. Ermöglicht deterministische Tests ohne I/O.

Wann aktivieren

• Schreiben von Swift-Code, der auf Dateisystem, Netzwerk oder externe APIs zugreift
• Notwendigkeit, Fehlerbehandlungspfade zu testen, ohne echte Fehler auszulösen
• Erstellen von Modulen, die über Umgebungen hinweg funktionieren (App, Test, SwiftUI-Vorschau)
• Entwerfen einer testbaren Architektur mit Swift Concurrency (Actors, Sendable)

Kernmuster

1. Definieren Sie kleine, fokussierte Protokolle

Jedes Protokoll behandelt genau einen externen Belang.

// Dateisystemzugriff
public protocol FileSystemProviding: Sendable {
    func containerURL(for purpose: Purpose) -> URL?
}

// Datei-Lese-/Schreiboperationen
public protocol FileAccessorProviding: Sendable {
    func read(from url: URL) throws -> Data
    func write(_ data: Data, to url: URL) throws
    func fileExists(at url: URL) -> Bool
}

// Bookmark-Speicherung (z. B. für sandboxed Apps)
public protocol BookmarkStorageProviding: Sendable {
    func saveBookmark(_ data: Data, for key: String) throws
    func loadBookmark(for key: String) throws -> Data?
}

2. Erstellen Sie Standard- (Produktions-) Implementierungen

public struct DefaultFileSystemProvider: FileSystemProviding {
    public init() {}

    public func containerURL(for purpose: Purpose) -> URL? {
        FileManager.default.url(forUbiquityContainerIdentifier: nil)
    }
}

public struct DefaultFileAccessor: FileAccessorProviding {
    public init() {}

    public func read(from url: URL) throws -> Data {
        try Data(contentsOf: url)
    }

    public func write(_ data: Data, to url: URL) throws {
        try data.write(to: url, options: .atomic)
    }

    public func fileExists(at url: URL) -> Bool {
        FileManager.default.fileExists(atPath: url.path)
    }
}

3. Erstellen Sie Mock-Implementierungen für Tests

public final class MockFileAccessor: FileAccessorProviding, @unchecked Sendable {
    public var files: [URL: Data] = [:]
    public var readError: Error?
    public var writeError: Error?

    public init() {}

    public func read(from url: URL) throws -> Data {
        if let error = readError { throw error }
        guard let data = files[url] else {
            throw CocoaError(.fileReadNoSuchFile)
        }
        return data
    }

    public func write(_ data: Data, to url: URL) throws {
        if let error = writeError { throw error }
        files[url] = data
    }

    public func fileExists(at url: URL) -> Bool {
        files[url] != nil
    }
}

4. Injizieren Sie Abhängigkeiten mit Standardparametern

Produktionscode verwendet Standardwerte; Tests injizieren Mocks.

public actor SyncManager {
    private let fileSystem: FileSystemProviding
    private let fileAccessor: FileAccessorProviding

    public init(
        fileSystem: FileSystemProviding = DefaultFileSystemProvider(),
        fileAccessor: FileAccessorProviding = DefaultFileAccessor()
    ) {
        self.fileSystem = fileSystem
        self.fileAccessor = fileAccessor
    }

    public func sync() async throws {
        guard let containerURL = fileSystem.containerURL(for: .sync) else {
            throw SyncError.containerNotAvailable
        }
        let data = try fileAccessor.read(
            from: containerURL.appendingPathComponent("data.json")
        )
        // Daten verarbeiten...
    }
}

5. Schreiben Sie Tests mit Swift Testing

import Testing

@Test("Sync-Manager behandelt fehlenden Container")
func testMissingContainer() async {
    let mockFileSystem = MockFileSystemProvider(containerURL: nil)
    let manager = SyncManager(fileSystem: mockFileSystem)

    await #expect(throws: SyncError.containerNotAvailable) {
        try await manager.sync()
    }
}

@Test("Sync-Manager liest Daten korrekt")
func testReadData() async throws {
    let mockFileAccessor = MockFileAccessor()
    mockFileAccessor.files[testURL] = testData

    let manager = SyncManager(fileAccessor: mockFileAccessor)
    let result = try await manager.loadData()

    #expect(result == expectedData)
}

@Test("Sync-Manager behandelt Lesefehler ordnungsgemäß")
func testReadError() async {
    let mockFileAccessor = MockFileAccessor()
    mockFileAccessor.readError = CocoaError(.fileReadCorruptFile)

    let manager = SyncManager(fileAccessor: mockFileAccessor)

    await #expect(throws: SyncError.self) {
        try await manager.sync()
    }
}

Best Practices

• Einzelne Verantwortung: Jedes Protokoll sollte einen Belang behandeln – erstellen Sie keine "Gott-Protokolle" mit vielen Methoden
• Sendable-Konformität: Erforderlich, wenn Protokolle über Actor-Grenzen hinweg verwendet werden
• Standardparameter: Lassen Sie Produktionscode standardmäßig echte Implementierungen verwenden; nur Tests müssen Mocks angeben
• Fehlersimulation: Entwerfen Sie Mocks mit konfigurierbaren Fehlereigenschaften zum Testen von Fehlerpfaden
• Nur Grenzen mocken: Mocken Sie externe Abhängigkeiten (Dateisystem, Netzwerk, APIs), nicht interne Typen

Anti-Patterns, die vermieden werden sollten

• Erstellen eines einzelnen großen Protokolls, das den gesamten externen Zugriff abdeckt
• Mocken interner Typen ohne externe Abhängigkeiten
• Verwenden von #if DEBUG-Bedingungen anstelle einer ordnungsgemäßen Abhängigkeitsinjektion
• Vergessen der Sendable-Konformität bei Verwendung mit Actors
• Über-Engineering: Wenn ein Typ keine externen Abhängigkeiten hat, benötigt er kein Protokoll

Wann verwenden

• Jeder Swift-Code, der das Dateisystem, Netzwerk oder externe APIs berührt
• Testen von Fehlerbehandlungspfaden, die in echten Umgebungen schwer auszulösen sind
• Erstellen von Modulen, die in App-, Test- und SwiftUI-Vorschaukontexten funktionieren müssen
• Apps, die Swift Concurrency (Actors, strukturierte Nebenläufigkeit) verwenden und eine testbare Architektur benötigen