Introduced at WWDC 2024 and shipped with Swift 6 and Xcode 16, Swift Testing represents a complete reimagining of how testing works in Swift. This framework replaces XCTest's 40+ assertions with just two macros: `#expect` and `#require`. Interviewers now regularly test this knowledge during iOS technical interviews. Each section mirrors a technical interview question with detailed answers and working code. The progression moves from fundamental concepts to advanced patterns. ## Swift Testing Fundamentals ### Question 1: What are the major differences between Swift Testing and XCTest? Swift Testing brings five fundamental changes compared to XCTest: 1. **Declarative syntax**: `@Test` attribute instead of `test` prefixes 2. **Two universal macros**: `#expect` and `#require` replace 40+ assertions 3. **Parallel by default**: all tests run concurrently 4. **Native async support**: complete Swift Concurrency integration 5. **Cross-platform**: works on Apple platforms, Linux, and Windows ```swift // TestComparison.swift import XCTest import Testing // ❌ Legacy XCTest pattern class UserServiceXCTests: XCTestCase { // Must start with "test" func testUserCreation() { let user = User(name: "Alice", age: 25) // Multiple verbose assertions XCTAssertNotNil(user) XCTAssertEqual(user.name, "Alice") XCTAssertGreaterThan(user.age, 18) XCTAssertTrue(user.isValid) } } // ✅ Modern Swift Testing pattern @Test("User creation with valid data") func userCreation() { let user = User(name: "Alice", age: 25) // Single macro for all verifications #expect(user.name == "Alice") #expect(user.age > 18) #expect(user.isValid) } ``` The key difference lies in expressiveness: Swift Testing uses standard Swift expressions instead of specialized assertions, making tests more readable and error messages more informative. ### Question 2: How does the #expect macro work? The `#expect` macro validates that a boolean expression is true. It automatically captures evaluated values to provide detailed error messages. Unlike `XCTAssert`, it uses native Swift syntax. ```swift // ExpectMacroBasics.swift import Testing @Test func basicExpectations() { let numbers = [1, 2, 3, 4, 5] let user = User(name: "Bob", email: "bob@example.com") // Simple comparisons - standard Swift expression #expect(numbers.count == 5) #expect(user.name == "Bob") // Comparisons with operators #expect(numbers.first! < numbers.last!) #expect(user.email.contains("@")) // Nil checking #expect(numbers.first != nil) // Collection verification #expect(numbers.contains(3)) #expect(!numbers.isEmpty) } @Test func expectWithCustomMessage() { let balance = 150.0 let withdrawAmount = 200.0 // Custom message to clarify intent #expect( balance >= withdrawAmount, "Insufficient funds: balance \(balance) < withdrawal \(withdrawAmount)" ) } ``` When an `#expect` fails, the test continues execution. This characteristic allows collecting multiple failures in a single test run, facilitating diagnosis. ### Question 3: What's the difference between #expect and #require? The fundamental difference concerns behavior after failure: - `#expect`: records the failure and **continues** execution - `#require`: records the failure and **stops** the test immediately `#require` must always be used with `try` because it can throw an error. ```swift // ExpectVsRequire.swift import Testing struct ApiResponse { let data: Data? let items: [Item]? } @Test func demonstrateExpectContinues() { let values = [1, 2, 3] // First #expect fails but test continues #expect(values.count == 10) // ❌ Failure recorded // These verifications still execute #expect(values.first == 1) // ✅ Success #expect(values.last == 3) // ✅ Success // Result: 1 failure, 2 successes in the same test } @Test func demonstrateRequireStops() throws { let response = ApiResponse(data: nil, items: nil) // #require stops immediately if condition fails let data = try #require(response.data) // ❌ Failure and STOP // This code NEVER executes if data is nil let json = try JSONDecoder().decode(User.self, from: data) #expect(json.name == "Alice") } ``` In practice, `#require` perfectly replaces `XCTUnwrap` for safe optional unwrapping. Use `#require` when subsequent steps depend on the result (unwrapping, preconditions). Use `#expect` for independent verifications that can fail without blocking the rest of the test. ## Advanced Patterns with #require ### Question 4: How to use #require for optional unwrapping? `#require` excels at optional unwrapping. It returns the non-optional value if it exists, or immediately fails the test if `nil`. ```swift // RequireUnwrapping.swift import Testing struct UserProfile { let id: Int let name: String let settings: Settings? } struct Settings { let theme: String let notifications: Bool } @Test func unwrapOptionalChain() throws { let profile = UserProfile( id: 1, name: "Alice", settings: Settings(theme: "dark", notifications: true) ) // Safe unwrap - stops if nil let settings = try #require(profile.settings) // Now settings is no longer optional #expect(settings.theme == "dark") #expect(settings.notifications == true) } @Test func unwrapArrayElement() throws { let users = ["Alice", "Bob", "Charlie"] // Unwrap first element let firstUser = try #require(users.first) #expect(firstUser == "Alice") // Unwrap with safe index let secondUser = try #require(users[safe: 1]) #expect(secondUser == "Bob") } @Test func unwrapDictionaryValue() throws { let config: [String: Any] = [ "apiUrl": "https://api.example.com", "timeout": 30, "retryCount": 3 ] // Unwrap and cast in a single operation let apiUrl = try #require(config["apiUrl"] as? String) let timeout = try #require(config["timeout"] as? Int) #expect(apiUrl.contains("https")) #expect(timeout > 0) } ``` This approach eliminates `guard let` pyramids and makes test code linear and readable. ### Question 5: How to test that a function throws an error? Swift Testing offers `#expect(throws:)` to verify that a function throws a specific error. ```swift // ErrorTesting.swift import Testing enum ValidationError: Error, Equatable { case emptyName case invalidEmail case underAge(minimum: Int) } struct Validator { static func validateUser(name: String, email: String, age: Int) throws { guard !name.isEmpty else { throw ValidationError.emptyName } guard email.contains("@") else { throw ValidationError.invalidEmail } guard age >= 18 else { throw ValidationError.underAge(minimum: 18) } } } @Test func testThrowsSpecificError() { // Verify a specific error is thrown #expect(throws: ValidationError.emptyName) { try Validator.validateUser(name: "", email: "test@mail.com", age: 25) } #expect(throws: ValidationError.invalidEmail) { try Validator.validateUser(name: "Alice", email: "invalid", age: 25) } } @Test func testThrowsErrorType() { // Verify error type without specific value #expect(throws: ValidationError.self) { try Validator.validateUser(name: "Bob", email: "bob@mail.com", age: 15) } } @Test func testThrowsWithInspection() throws { // Capture error for detailed inspection let error = try #require( throws: ValidationError.self ) { try Validator.validateUser(name: "Charlie", email: "charlie@mail.com", age: 16) } // Verify error details if case .underAge(let minimum) = error { #expect(minimum == 18) } } ``` This syntax replaces `XCTAssertThrowsError` with a clearer, type-safe API. ## Test Organization with @Test and @Suite ### Question 6: How to organize tests with @Suite? `@Suite` logically groups related tests. Unlike `XCTestCase`, it doesn't require class inheritance. ```swift // TestSuiteOrganization.swift import Testing // Suite for authentication tests @Suite("Authentication Tests") struct AuthenticationTests { // Shared property for all tests in the suite let authService = AuthService() @Test("Login with valid credentials succeeds") func loginWithValidCredentials() async throws { let result = try await authService.login( email: "user@example.com", password: "validPass123" ) #expect(result.isSuccess) let token = try #require(result.token) #expect(!token.isEmpty) } @Test("Login with invalid password fails") func loginWithInvalidPassword() async { let result = await authService.login( email: "user@example.com", password: "wrong" ) #expect(!result.isSuccess) #expect(result.error == .invalidCredentials) } } // Nested suites for hierarchical organization @Suite("User Management") struct UserManagementTests { @Suite("Creation") struct CreationTests { @Test func createUserWithValidData() { // Creation test } @Test func createUserWithDuplicateEmail() { // Duplicate error test } } @Suite("Deletion") struct DeletionTests { @Test func deleteExistingUser() { // Deletion test } @Test func deleteNonExistentUser() { // Error test } } } ``` Suites allow running test subsets and organizing reports in a readable way. ### Question 7: How to use traits to configure tests? Traits modify test behavior: execution conditions, tags, timeouts, etc. ```swift // TestTraits.swift import Testing @Suite("API Integration Tests") struct APITests { // Temporarily disabled test @Test(.disabled("Backend under maintenance")) func fetchUserProfile() async { // Does not execute } // Conditional test based on platform @Test @available(iOS 17, *) func useNewAPIFeature() { // Executes only on iOS 17+ } // Test with tags for filtering @Test(.tags(.critical, .network)) func criticalNetworkOperation() async throws { // Tagged test for filtering } // Test with custom timeout @Test(.timeLimit(.minutes(2))) func longRunningOperation() async { // Must complete within 2 minutes } // Trait combination @Test( "Complex data sync", .tags(.slow), .timeLimit(.minutes(5)), .bug("JIRA-1234", "Flaky on CI") ) func complexDataSync() async throws { // Test documented with known bug } } // Custom tag definitions extension Tag { @Tag static var critical: Self @Tag static var network: Self @Tag static var slow: Self } ``` Traits make tests self-documenting and enable selective execution via command line. ## Parameterized Tests ### Question 8: How to create parameterized tests? Swift Testing allows running the same test with different inputs via parameters. ```swift // ParameterizedTests.swift import Testing struct EmailValidator { static func isValid(_ email: String) -> Bool { let pattern = #"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$"# return email.range(of: pattern, options: .regularExpression) != nil } } // Parameterized test with a collection @Test(arguments: [ "user@example.com", "test.name@domain.org", "contact@company.co.uk" ]) func validEmailsAreAccepted(email: String) { #expect(EmailValidator.isValid(email)) } @Test(arguments: [ "invalid", "@nodomain.com", "no@tld", "spaces in@email.com" ]) func invalidEmailsAreRejected(email: String) { #expect(!EmailValidator.isValid(email)) } // Test with tuples for input/output cases @Test(arguments: [ ("hello", "HELLO"), ("World", "WORLD"), ("Swift", "SWIFT") ]) func uppercaseConversion(input: String, expected: String) { #expect(input.uppercased() == expected) } // Test with Cartesian product of two collections @Test(arguments: [1, 2, 3], ["a", "b"]) func combinationTest(number: Int, letter: String) { // Runs for (1,"a"), (1,"b"), (2,"a"), (2,"b"), (3,"a"), (3,"b") let combined = "\(number)\(letter)" #expect(combined.count == 2) } ``` Each parameter combination generates an independent test, making it easy to identify failing cases. ### Question 9: How to test asynchronous code? Swift Testing natively integrates async/await, drastically simplifying asynchronous tests. ```swift // AsyncTesting.swift import Testing actor DataStore { private var items: [String] = [] func add(_ item: String) { items.append(item) } func getAll() -> [String] { items } func clear() { items.removeAll() } } @Suite("Async Operations") struct AsyncTests { @Test func basicAsyncOperation() async { // No need for expectation or wait let result = await fetchData() #expect(!result.isEmpty) } @Test func asyncWithTimeout() async throws { // Use Task.sleep to simulate delay try await Task.sleep(for: .milliseconds(100)) let data = await loadConfiguration() let config = try #require(data) #expect(config.isValid) } @Test func testActorIsolation() async { let store = DataStore() // Operations on actor sequentially await store.add("Item 1") await store.add("Item 2") let items = await store.getAll() #expect(items.count == 2) #expect(items.contains("Item 1")) } @Test func testConcurrentOperations() async { let store = DataStore() // Concurrent execution with TaskGroup await withTaskGroup(of: Void.self) { group in for i in 1...10 { group.addTask { await store.add("Item \(i)") } } } let items = await store.getAll() #expect(items.count == 10) } } // Async helpers for tests func fetchData() async -> [String] { try? await Task.sleep(for: .milliseconds(50)) return ["data1", "data2"] } func loadConfiguration() async -> Configuration? { Configuration(isValid: true) } struct Configuration { let isValid: Bool } ``` Swift Testing runs tests in parallel by default. For tests that modify shared state, use `.serialized` on the suite or isolate state with actors. ## XCTest to Swift Testing Migration ### Question 10: How to migrate progressively from XCTest? Both frameworks coexist in the same project. A progressive migration is recommended. ```swift // MigrationStrategy.swift import XCTest import Testing // ⚠️ CRITICAL RULE: Never mix frameworks in the same test // ❌ INCORRECT - Mixing forbidden class BadMixedTest: XCTestCase { func testMixed() { #expect(true) // Does not work in XCTestCase } } // ✅ CORRECT - Pure XCTest for existing tests class LegacyUserTests: XCTestCase { func testUserCreation() { let user = User(name: "Test") XCTAssertNotNil(user) XCTAssertEqual(user.name, "Test") } } // ✅ CORRECT - Swift Testing for new tests @Suite("User Tests - Modern") struct ModernUserTests { @Test func userCreation() { let user = User(name: "Test") #expect(user.name == "Test") } } // Migration strategy by file // 1. Identify tests to migrate (start with simplest) // 2. Create new file with @Suite // 3. Rewrite tests one by one // 4. Delete old XCTest file once validated ``` | XCTest | Swift Testing | |--------|---------------| | `XCTAssertTrue(x)` | `#expect(x)` | | `XCTAssertFalse(x)` | `#expect(!x)` | | `XCTAssertEqual(a, b)` | `#expect(a == b)` | | `XCTAssertNil(x)` | `#expect(x == nil)` | | `XCTAssertNotNil(x)` | `#expect(x != nil)` | | `XCTUnwrap(x)` | `try #require(x)` | | `XCTAssertThrowsError` | `#expect(throws:)` | ### Question 11: What XCTest features are not yet in Swift Testing? Swift Testing (Swift 6) doesn't yet cover all XCTest use cases. ```swift // MissingFeatures.swift // ❌ NOT SUPPORTED: Performance tests // Stick with XCTest for measuring performance class PerformanceTests: XCTestCase { func testPerformance() { measure { // Code to measure _ = (0..<1000).map { $0 * 2 } } } } // ❌ NOT SUPPORTED: UI tests (XCUITest) // Continue using XCUITest for interface tests class UITests: XCTestCase { func testLoginFlow() { let app = XCUIApplication() app.launch() // UI tests... } } // ✅ SUPPORTED: Async integration tests @Test func integrationTest() async throws { let api = APIClient() let response = try await api.fetchUsers() #expect(!response.isEmpty) } // ✅ SUPPORTED: Mocking with protocols @Test func mockingWithProtocols() async { let mockService = MockUserService() let viewModel = UserViewModel(service: mockService) await viewModel.loadUser(id: 1) #expect(viewModel.user?.name == "Mock User") } ``` For projects with UI or performance tests, maintain XCTest for those specific cases. ## Tricky Interview Questions ### Question 12: Why does #require need try but not #expect? `#require` can throw an error if the condition fails because it must interrupt the test. `#expect` only records the failure and continues, so it doesn't throw. ```swift // RequireTryExplanation.swift import Testing @Test func explainTryRequirement() throws { let optionalValue: String? = nil // #expect returns Void - no error thrown // Test continues even if it fails #expect(optionalValue != nil) // No try // #require can throw ExpectationFailedError // Test stops if it fails // Must be marked with try let value = try #require(optionalValue) // Requires try // If we reach here, optionalValue was not nil #expect(!value.isEmpty) } // The internal signature resembles: // func #expect(_ condition: Bool) -> Void // func #require(_ value: T?) throws -> T ``` This architectural distinction allows the compiler to guarantee correct failure handling. ### Question 13: How does Swift Testing handle parallelism? By default, all tests run in parallel, which speeds up test suites but requires proper state isolation. ```swift // ParallelismHandling.swift import Testing // ❌ PROBLEM: Mutable shared state var sharedCounter = 0 // Dangerous in parallel! @Suite("Problematic Parallel Tests") struct ProblematicTests { @Test func incrementCounter1() { sharedCounter += 1 // Race condition! } @Test func incrementCounter2() { sharedCounter += 1 // Race condition! } } // ✅ SOLUTION 1: Force sequential execution @Suite("Sequential Tests", .serialized) struct SequentialTests { static var counter = 0 @Test func first() { Self.counter += 1 #expect(Self.counter == 1) } @Test func second() { Self.counter += 1 #expect(Self.counter == 2) } } // ✅ SOLUTION 2: Isolate state per test @Suite("Isolated Tests") struct IsolatedTests { @Test func independentTest1() { var localCounter = 0 localCounter += 1 #expect(localCounter == 1) } @Test func independentTest2() { var localCounter = 0 localCounter += 1 #expect(localCounter == 1) } } // ✅ SOLUTION 3: Use actor for shared state actor TestState { var value = 0 func increment() -> Int { value += 1 return value } } @Suite("Actor-based Tests") struct ActorTests { let state = TestState() @Test func safeIncrement() async { let result = await state.increment() #expect(result > 0) } } ``` The `.serialized` trait guarantees sequential execution of an entire suite. ### Question 14: How to use confirmations for callbacks? For APIs with callbacks (non-async), Swift Testing offers `confirmation`. ```swift // ConfirmationPattern.swift import Testing // Legacy service with callback class LegacyService { func fetchData(completion: @escaping (Result) -> Void) { DispatchQueue.global().asyncAfter(deadline: .now() + 0.1) { completion(.success("Data loaded")) } } } @Test func testCallbackWithConfirmation() async { let service = LegacyService() // confirmation waits for it to be called await confirmation("Data callback received") { confirm in service.fetchData { result in if case .success(let data) = result { #expect(data == "Data loaded") confirm() // Signals callback was executed } } } } // For callbacks called multiple times @Test func testMultipleCallbacks() async { let publisher = EventPublisher() // expectedCount specifies expected call count await confirmation("Events received", expectedCount: 3) { confirm in publisher.onEvent = { event in #expect(!event.isEmpty) confirm() // Called 3 times } publisher.emit("Event 1") publisher.emit("Event 2") publisher.emit("Event 3") } } class EventPublisher { var onEvent: ((String) -> Void)? func emit(_ event: String) { DispatchQueue.global().async { self.onEvent?(event) } } } ``` `confirmation` elegantly replaces `XCTestExpectation` and `wait(for:timeout:)`. ## Conclusion Swift Testing represents the future of testing on Apple platforms. The two macros `#expect` and `#require` dramatically simplify test writing while improving error message quality. **Key points to remember for interviews:** - ✅ `#expect` continues after failure, `#require` stops immediately - ✅ `#require` requires `try` because it can throw an error - ✅ Swift Testing runs in parallel by default - ✅ Both frameworks coexist but must not be mixed in the same test - ✅ XCTest remains necessary for UI and performance tests - ✅ Traits allow fine-grained test behavior configuration - ✅ Parameterized tests avoid code duplication Migration to Swift Testing can be done progressively, file by file, starting with the simplest tests.