Swift Testing Framework Rozmowa kwalifikacyjna 2026: Makra #expect i #require vs XCTest
Opanuj nowy Swift Testing Framework na rozmowy iOS: makra #expect i #require, migracja z XCTest, zaawansowane wzorce i typowe pułapki.

Zaprezentowany na WWDC 2024 i wydany razem ze Swift 6 oraz Xcode 16, Swift Testing stanowi kompletne przemyślenie sposobu działania testów w Swift. Ten framework zastępuje ponad 40 asercji z XCTest zaledwie dwoma makrami: #expect oraz #require. Rekruterzy regularnie weryfikują tę wiedzę podczas technicznych rozmów iOS.
Każda sekcja odzwierciedla pytanie z technicznej rozmowy kwalifikacyjnej wraz ze szczegółowymi odpowiedziami i działającym kodem. Progresja prowadzi od podstawowych pojęć do zaawansowanych wzorców.
Podstawy Swift Testing
Pytanie 1: Jakie są główne różnice między Swift Testing a XCTest?
Swift Testing wprowadza pięć fundamentalnych zmian względem XCTest:
- Składnia deklaratywna: atrybut
@Testzamiast prefiksówtest - Dwa uniwersalne makra:
#expecti#requirezastępują ponad 40 asercji - Domyślnie równoległe: wszystkie testy działają współbieżnie
- Natywne wsparcie async: pełna integracja ze Swift Concurrency
- Wieloplatformowe: działa na platformach Apple, Linux i Windows
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)
}Kluczowa różnica leży w ekspresyjności: Swift Testing wykorzystuje standardowe wyrażenia Swift zamiast wyspecjalizowanych asercji, co czyni testy czytelniejszymi, a komunikaty o błędach bardziej informatywnymi.
Pytanie 2: Jak działa makro #expect?
Makro #expect weryfikuje, że wyrażenie logiczne jest prawdziwe. Automatycznie przechwytuje wartości obliczone, dostarczając szczegółowe komunikaty błędów. W przeciwieństwie do XCTAssert używa natywnej składni 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)"
)
}Gdy #expect zawodzi, test kontynuuje wykonywanie. Ta cecha pozwala zebrać wiele błędów w jednym uruchomieniu, co ułatwia diagnostykę.
Pytanie 3: Jaka jest różnica między #expect a #require?
Fundamentalna różnica dotyczy zachowania po niepowodzeniu:
#expect: rejestruje błąd i kontynuuje wykonywanie#require: rejestruje błąd i natychmiast zatrzymuje test
#require musi być zawsze używane z try, ponieważ może rzucić błąd.
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")
}W praktyce #require doskonale zastępuje XCTUnwrap przy bezpiecznym rozpakowywaniu opcjonali.
Używaj #require, gdy kolejne kroki zależą od wyniku (rozpakowanie, warunki wstępne). Używaj #expect do niezależnych weryfikacji, które mogą zawieść bez blokowania reszty testu.
Zaawansowane wzorce z #require
Pytanie 4: Jak używać #require do rozpakowywania opcjonali?
#require wyróżnia się przy rozpakowywaniu opcjonali. Zwraca wartość nieopcjonalną jeśli istnieje, lub natychmiast oblewa test, jeśli wartość to nil.
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)
}To podejście eliminuje piramidy guard let i sprawia, że kod testów jest liniowy i czytelny.
Pytanie 5: Jak testować, że funkcja rzuca błąd?
Swift Testing oferuje #expect(throws:) do weryfikacji, że funkcja rzuca konkretny błąd.
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)
}
}Ta składnia zastępuje XCTAssertThrowsError jaśniejszym i bezpiecznym typowo API.
Gotowy na rozmowy o iOS?
Ćwicz z naszymi interaktywnymi symulatorami, flashcards i testami technicznymi.
Organizacja testów z @Test i @Suite
Pytanie 6: Jak organizować testy z @Suite?
@Suite logicznie grupuje powiązane testy. W przeciwieństwie do XCTestCase nie wymaga dziedziczenia po klasie.
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 pozwalają uruchamiać podzbiory testów i organizować raporty w czytelny sposób.
Pytanie 7: Jak używać traits do konfiguracji testów?
Traits modyfikują zachowanie testów: warunki wykonywania, tagi, timeouty itp.
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 czynią testy samodokumentującymi i umożliwiają selektywne uruchamianie z linii poleceń.
Testy parametryzowane
Pytanie 8: Jak tworzyć testy parametryzowane?
Swift Testing pozwala uruchomić ten sam test z różnymi danymi wejściowymi przez parametry.
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)
}Każda kombinacja parametrów generuje niezależny test, co ułatwia identyfikację oblanych przypadków.
Pytanie 9: Jak testować kod asynchroniczny?
Swift Testing natywnie integruje async/await, drastycznie upraszczając testy asynchroniczne.
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 domyślnie uruchamia testy równolegle. Dla testów modyfikujących stan współdzielony użyj .serialized na suite lub izoluj stan przez aktorów.
Migracja z XCTest do Swift Testing
Pytanie 10: Jak stopniowo migrować z XCTest?
Oba frameworki współistnieją w tym samym projekcie. Zalecana jest stopniowa migracja.
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:) |
Pytanie 11: Których funkcji XCTest nadal nie ma w Swift Testing?
Swift Testing (Swift 6) nie pokrywa jeszcze wszystkich przypadków użycia XCTest.
// ❌ 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")
}W projektach z testami UI lub wydajnościowymi pozostaw XCTest dla tych konkretnych przypadków.
Gotowy na rozmowy o iOS?
Ćwicz z naszymi interaktywnymi symulatorami, flashcards i testami technicznymi.
Podchwytliwe pytania rekrutacyjne
Pytanie 12: Dlaczego #require wymaga try, a #expect nie?
#require może rzucić błąd, jeśli warunek zawiedzie, ponieważ musi przerwać test. #expect jedynie rejestruje błąd i kontynuuje, więc niczego nie rzuca.
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<T>(_ value: T?) throws -> TTo architektoniczne rozróżnienie pozwala kompilatorowi gwarantować poprawną obsługę błędów.
Pytanie 13: Jak Swift Testing zarządza równoległością?
Domyślnie wszystkie testy działają równolegle, co przyspiesza suites, ale wymaga prawidłowej izolacji stanu.
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)
}
}Trait .serialized gwarantuje sekwencyjne wykonanie całej suite.
Pytanie 14: Jak używać confirmations dla callbacków?
Dla API z callbackami (nie-async) Swift Testing oferuje confirmation.
import Testing
// Legacy service with callback
class LegacyService {
func fetchData(completion: @escaping (Result<String, Error>) -> 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 elegancko zastępuje XCTestExpectation oraz wait(for:timeout:).
Podsumowanie
Swift Testing reprezentuje przyszłość testowania na platformach Apple. Dwa makra #expect i #require drastycznie upraszczają pisanie testów, jednocześnie poprawiając jakość komunikatów błędów.
Kluczowe punkty do zapamiętania na rozmowy:
- ✅
#expectkontynuuje po niepowodzeniu,#requirezatrzymuje natychmiast - ✅
#requirewymagatry, ponieważ może rzucić błąd - ✅ Swift Testing domyślnie uruchamia się równolegle
- ✅ Oba frameworki współistnieją, ale nie wolno ich mieszać w tym samym teście
- ✅ XCTest pozostaje konieczny dla testów UI i wydajnościowych
- ✅ Traits umożliwiają precyzyjną konfigurację zachowania testów
- ✅ Testy parametryzowane eliminują duplikację kodu
Migrację do Swift Testing można wykonać stopniowo, plik po pliku, zaczynając od najprostszych testów.
Zacznij ćwiczyć!
Sprawdź swoją wiedzę z naszymi symulatorami rozmów i testami technicznymi.
Tagi
Udostępnij
Powiązane artykuły

Rozmowa Kwalifikacyjna StoreKit 2: Zarządzanie Subskrypcjami i Walidacja Paragonów
Opanuj pytania na rozmowy iOS dotyczące StoreKit 2, zarządzania subskrypcjami, walidacji paragonów i implementacji zakupów w aplikacji z praktycznymi przykładami kodu Swift.

Rozmowa kwalifikacyjna iOS Push Notifications 2026: APNs, tokeny i troubleshooting
Kompleksowy przewodnik przygotowujący do rozmów kwalifikacyjnych iOS dotyczących Push Notifications, APNs, zarządzania tokenami i rozwiązywania problemów. Najczęstsze pytania ze szczegółowymi odpowiedziami.

Top 25 pytań rekrutacyjnych ze Swift dla programistów iOS
Przygotowanie do rozmów rekrutacyjnych na stanowisko iOS: 25 najczęściej zadawanych pytań ze Swift dotyczących optionali, closures, ARC, protokołów, async/await i zaawansowanych wzorców.