iOS Architecture
Use Swift Testing, focused fakes, and a balanced test strategy to verify behavior without coupling tests to implementation details.
Before you begin
Learning stage
Testability is architectural feedback. If a business rule requires a simulator, network, database, and navigation stack before it can be verified, responsibilities are probably too tightly connected. Good boundaries let fast tests exercise policy directly while a smaller number of integration and UI tests verify that real pieces connect and users can complete important workflows.
A fake is a lightweight working implementation, such as an in-memory repository. A stub returns controlled values, while a spy records interactions for later verification. Prefer state or returned-result assertions over verifying every internal method call. A mock with rigid interaction expectations can make harmless refactoring expensive when the interaction itself is not the behavior under test.
Swift Testing provides @Test, #expect, #require, parameterized tests, traits, and native concurrency support for unit and integration tests. XCTest remains important for UI automation and established suites. Inject clocks, identifiers, repositories, and failure behavior so tests are deterministic, isolated, and safe to run in parallel.
Learning stage
An actor-backed fake and fixed clock verify a use case without networking, persistence, waiting, or global state.
import Foundation
import Testing
@testable import LearningDomain
actor ProgressStoreFake: ProgressSaving {
private var stored: [LessonProgress] = []
func save(_ progress: LessonProgress) async throws {
stored.append(progress)
}
func values() -> [LessonProgress] { stored }
}
@Suite("Complete lesson")
struct CompleteLessonTests {
@Test("Records the selected lesson with the current date")
func recordsProgress() async throws {
let store = ProgressStoreFake()
let date = Date(timeIntervalSince1970: 1_800_000_000)
let lessonID = UUID(uuidString: "AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE")!
let completeLesson = CompleteLesson(
progressStore: store,
now: { date }
)
try await completeLesson(lessonID: lessonID)
let saved = await store.values()
#expect(saved == [LessonProgress(lessonID: lessonID, completedAt: date)])
}
}
@Test("Certificates require every lesson", arguments: [0, 3, 4])
func certificateRule(completed: Int) {
let course = Course(
id: UUID(uuidString: "11111111-2222-3333-4444-555555555555")!,
title: "Architecture",
completedLessons: completed,
totalLessons: 4
)
#expect(course.canReceiveCertificate == (completed == 4))
}Learning stage
Connect the architectural concept to maintainable iOS features and real change scenarios.
Learning stage
Identify abstractions and dependencies that add coupling, ambiguity, or unnecessary ceremony.
Learning stage
Apply the design to a small feature and evaluate it through observable change scenarios.
Activity 1
For a course editor, assign validation, saving, repository mapping, navigation, accessibility, and full creation flow to unit, integration, UI, or performance tests.
Hint: Use the lowest-cost test that observes the risk, then add a few high-fidelity workflows.
Activity 2
Refactor a test that depends on Date(), UUID(), a live API, and Task.sleep so each external input is controlled.
Hint: Inject tiny closures when a full protocol would add no value.
Learning stage
Answer each question before revealing the explanation.
QUESTION 1
A fake has a simplified working implementation; a stub returns controlled output
Both are test doubles, but their behavior and intended use differ.
QUESTION 2
UI tests are slower and more variable, and they provide less focused failure feedback than direct unit tests.
Use UI tests for critical user workflows and faster tests for detailed logic and edge cases.
Learning stage
Explain the decision, dependency direction, trade-offs, and evidence—not only the pattern name.
Short answer: Clear boundaries make important rules directly testable and reserve integration or UI tests for connections and user workflows.
I test domain transitions and presentation state with fast Swift Testing tests, use fakes or stubs at external boundaries, add integration tests for adapters and persistence, and keep UI tests focused on high-value flows. I inject nondeterministic values, assert observable behavior instead of private implementation, and use test plans to balance local feedback with broader confidence.
Possible follow-ups
Learning stage
A healthy architecture creates fast, deterministic seams for policy tests while preserving a smaller number of realistic integration and UI checks.