XCTest: concepte cheie, clasele XCTestCase și scrierea testelor

Ce este XCTest?

XCTest — este un framework pentru testare modulară, de integrare și UI, dezvoltat de Apple și integrat în Xcode începând cu versiunea 5.0 (2013). XCTest a înlocuit OCUnit (SenTestingKit) și a oferit un API modern în Swift cu suport pentru teste asincrone, teste de performanță și integrare cu Xcode Server. Conform Swift.org (2024), XCTest este baza testării în toate proiectele Apple, inclusiv Swift Package Manager, care utilizează XCTest pentru autoverificare.

XCTest funcționează împreună cu Xcode Test Navigator și Report Navigator, care arată arborele testelor, istoricul de rulare și compară rezultatele între compilări. Test Navigator permite rularea unui singur test, a unui grup de teste sau a întregului set fără modificarea codului. Rezultatele sunt afişate ca pictograme verzi (passed), roşii (failed) şi galbene (skipped). Conform Apple WWDC (2024), Xcode 16 a îmbunătățit rularea paralelă a testelor cu 40% prin utilizarea mai multor simulatoare.

XCTest suportă platformele: iOS 8.0+, macOS 10.10+, watchOS 2.0+, tvOS 9.0+. Pentru fiecare platformă este disponibil același API, ceea ce permite scrierea de teste cross-platform. Swift Testing — un nou framework Apple (anunțat în 2024), care în viitor va completa XCTest, dar nu îl va înlocui complet. XCTest rămâne framework-ul principal pentru testare în ecosistemul Apple.

XCTestCase — clasa de bază pentru teste

XCTestCase — este clasa de bază de care moștenesc toate clasele de test în XCTest. Aceasta oferă ciclul de viață al testului: `setUp()` este apelat înaintea fiecărui test, `tearDown()` — după fiecare test. SetUp este utilizat pentru inițializarea obiectelor și mock-urilor, tearDown — pentru curățarea resurselor. setUpWithError și tearDownWithError permit gestionarea erorilor de inițializare fără try-catch în fiecare test.

Fiecare metodă al cărei nume începe cu `test` este recunoscută automat de Xcode ca test. Alternativ, se poate utiliza macro-ul `@Test` (Swift Testing). Numele testului trebuie să fie descriptiv: `testLoginWithValidCredentials` este mai bun decât `testLogin1`. Documentarea testelor prin comentarii este o practică bună, dar Xcode permite adăugarea descrierii prin User-Defined Attributes.

import XCTest

class UserServiceTests: XCTestCase {

    var sut: UserService!
    var mockSession: MockURLSession!

    override func setUp() {
        mockSession = MockURLSession()
        sut = UserService(session: mockSession)
    }

    override func tearDown() {
        sut = nil
        mockSession = nil
    }

    func testFetchUser_ReturnsDecodedUser() {
        let json = "{\"id\": 1, \"name\": \"Alice\"}"
        mockSession.setResponse(json)
        let user = try await sut.fetchUser(id: 1)
        XCTAssertEqual(user.name, "Alice")
    }
}

Exemplul de mai sus demonstrează structura standard a XCTestCase. sut (System Under Test) — convenție de denumire a obiectului testat. MockURLSession înlocuiește rețeaua reală, permițând testarea UserService în izolare. Principiul „un test — o verificare” simplifică depanarea: dacă testul eșuează, dezvoltatorul știe imediat ce funcționalitate este stricată. Fiecare test XCTestCase ar trebui să verifice un singur scenariu sau o singură afirmație.

Aserțiuni în XCTest

Grupul de bază al aserțiunilor

XCTAssertTrue și XCTAssertFalse — aserțiuni de bază pentru verificarea valorilor booleene. XCTAssertTrue(expression) trece dacă expression == true. XCTAssertEqual verifică egalitatea a două valori cu suport pentru toate tipurile care implementează Equatable. Pentru numerele cu virgulă mobilă se utilizează XCTAssertEqual cu parametrul accuracy pentru a ține cont de eroarea de calcul. Conform Google Testing Blog (2024), XCTAssertEqual acoperă 70% din toate verificările într-un set tipic de teste.

Aserțiuni nil și erori

XCTAssertNil și XCTAssertNotNil verifică valorile opționale pentru nil. Aceste aserțiuni sunt critice pentru Swift, unde tipurile opționale sunt utilizate pe scară largă. XCTAssertThrowsError verifică dacă codul aruncă o eroare așteptată. XCTUnwrap — aserțiune care extrage valoarea opțională și eșuează cu un mesaj clar dacă valoarea este nil. Compararea șirurilor prin XCTAssertEqual utilizează compararea literală, nu cea semantică. XCTAssertNoThrow — aserțiune pereche pentru a verifica dacă codul nu aruncă o eroare.

XCTestExpectation și teste asincrone

XCTestExpectation — este un mecanism pentru testarea codului asincron. Testul creează o așteptare cu un nume descriptiv, o transmite operațiunii asincrone și apelează `wait(for:timeout:)`. Dacă așteptarea nu este îndeplinită în intervalul de timeout, testul eșuează. Timeout implicit este de 10 secunde, dar pentru operații rapide se recomandă setarea la 1–3 secunde pentru a accelera timpul total de testare.

XCTWaiter — o alternativă mai flexibilă la wait(for:timeout:). XCTWaiter permite așteptarea mai multor așteptări, configurarea ordinii de execuție și gestionarea timeout-urilor programatic. Spre deosebire de wait, XCTWaiter returnează `XCTWaiter.Result`, care poate fi analizat. Delegatul XCTWaiterDelegate notifică despre încălcarea ordinii așteptărilor și timeout-uri.

func testAsyncLogin() {
    let expectation = XCTestExpectation(description: "login")
    var resultUser: User?

    sut.login(email: "a@b.com", password: "123") { user in
        resultUser = user
        expectation.fulfill()
    }

    wait(for: [expectation], timeout: 3)
    XCTAssertNotNil(resultUser)
    XCTAssertEqual(resultUser?.email, "a@b.com")
}

În exemplu, XCTestExpectation este utilizat pentru testarea autentificării asincrone. fulfill() este apelat în interiorul callback-ului, semnalând că operațiunea asincronă s-a finalizat. Dacă în 3 secunde fulfill() nu este apelat — testul eșuează cu timeout. După așteptarea reușită, se execută aserțiunile pentru verificarea rezultatului. Așteptări multiple pot fi transmise ca matrice și se poate aștepta finalizarea tuturor.

Teste de performanță cu XCTest

measure(metrics:) — metoda XCTestCase pentru crearea testelor de performanță. Blocul de cod din interiorul measure este executat de 10 ori consecutiv, iar XCTest colectează statistici: timpul mediu, mediana, abaterea standard. Metrics — matricea de metrici urmărite: XCTClockMetric (timp), XCTMemoryMetric (memorie), XCTStorageMetric (disc) și XCTCPUMetric (procesor). Conform Apple WWDC (2024), testele de performanță cu XCTCPUMetric sunt utile pentru detectarea regresiilor în algoritmi.

Baseline (linia de bază) pentru testele de performanță se stabilește în Xcode Test Plan. Dacă timpul de execuție depășește baseline-ul cu un procent stabilit (implicit 10%), testul este considerat eșuat. Baseline-ul este actualizat manual după confirmarea că modificarea de performanță este așteptată. Test Plan în Xcode permite gruparea testelor de performanță pe configurații: debug/release, diferite dispozitive, diferite versiuni iOS.

func testArraySortPerformance() {
    let numbers = (1...10000).shuffled()
    measure(metrics: [XCTClockMetric()]) {
        let _ = numbers.sorted()
    }
}

Acest test de performanță măsoară timpul de sortare a unui tablou de 10000 de elemente. XCTClockMetric înregistrează timpul real de execuție. Dacă după modificarea algoritmului de sortare timpul crește cu 10% sau mai mult, testul va indica regresia. Testele de performanță XCTest sunt deosebit de utile pentru: algoritmi de procesare a datelor, randarea componentelor UI, operații cu baza de date și cereri de rețea.

Organizarea testelor și integrarea CI/CD

Structura proiectului de testare

Structura proiectului de testare în XCTest urmează convenția: un fișier de test per clasă, plasat într-un director separat `<TargetName>Tests`. Numele fișierelor corespund numelor claselor testate cu sufixul `Tests`: `UserService.swift` → `UserServiceTests.swift`. Test Targets în Xcode sunt configurate separat pentru testele unitare și testele UI, permițând rularea lor independentă. Scheme-urile în Xcode gestionează configurația de compilare și setul de teste executate.

Integrarea CI/CD

Xcode Cloud și GitHub Actions suportă rularea XCTest prin `xcodebuild test -scheme App -testPlan SmokeTest`. Pipeline-ul CI include: compilare → rulare teste unitare → rulare teste UI → publicare raport. Raportul JUnit este generat de `xcodebuild` cu opțiunea `-resultBundlePath` și poate fi importat în orice instrument CI. Code Coverage — funcție integrată în XCTest care arată ce linii de cod sunt acoperite de teste. Pragul minim de acoperire pentru codul de producție — 70% pentru logica de business critică.

Xcode Cloud și GitHub Actions suportă rularea XCTest prin `xcodebuild test -scheme App -testPlan SmokeTest`. Pipeline-ul CI include: compilare → rulare teste unitare → rulare teste UI → publicare raport. Raportul JUnit este generat de `xcodebuild` cu opțiunea `-resultBundlePath` și poate fi importat în orice instrument CI. Bitrise și Jenkins au pași gata pregătiți pentru XCTest.

Code Coverage — funcție integrată în XCTest care arată ce linii de cod sunt acoperite de teste. Xcode afișează acoperirea în verde (acoperit), roșu (neacoperit) și galben (parțial acoperit). Pragul minim de acoperire pentru codul de producție — 70% pentru logica de business critică. Conform Google Testing Blog (2024), impunerea obligatorie a 80% acoperire pentru toate modulele duce la apariția „testelor goale” care nu verifică logica, ci doar execută codul.