XCTest: kulcsfogalmak, XCTestCase osztályok és tesztek írása

Mi az XCTest?

XCTest — egy keretrendszer moduláris, integrációs és UI teszteléshez, amelyet az Apple fejlesztett ki és az Xcode-ba épített az 5.0 verziótól (2013) kezdve. Az XCTest felváltotta az OCUnit-ot (SenTestingKit), és modern API-t biztosított Swift-ben aszinkron tesztek, teljesítménytesztek és Xcode Server integráció támogatásával. A Swift.org (2024) szerint az XCTest a tesztelés alapja minden Apple projektben, beleértve a Swift Package Managert is, amely az XCTest-et használja önellenőrzésre.

Az XCTest az Xcode Test Navigator és Report Navigator segítségével működik, amelyek megjelenítik a tesztfát, a végrehajtási előzményeket és összehasonlítják az eredményeket a build-ek között. Test Navigator lehetővé teszi egyetlen teszt, tesztcsoport vagy a teljes készlet futtatását a kód módosítása nélkül. Az eredmények zöld (passed), piros (failed) és sárga (skipped) ikonként jelennek meg. Az Apple WWDC (2024) szerint az Xcode 16 40%-kal javította a párhuzamos tesztfuttatást több szimulátor használatával.

Az XCTest a következő platformokat támogatja: iOS 8.0+, macOS 10.10+, watchOS 2.0+, tvOS 9.0+. Minden platformhoz ugyanaz az API érhető el, ami lehetővé teszi a cross-platform tesztek írását. Swift Testing — egy új Apple keretrendszer (2024-ben bejelentve), amely a jövőben kiegészíti az XCTest-et, de nem váltja fel teljesen. Az XCTest továbbra is a fő tesztelési keretrendszer marad az Apple ökoszisztémában.

XCTestCase — az alaposztály a tesztekhez

XCTestCase — az alaposztály, amelyből az összes tesztosztály származik az XCTest-ben. Biztosítja a teszt életciklusát: a `setUp()` minden teszt előtt, a `tearDown()` minden teszt után hívódik meg. A setUp az objektumok és mock-ok inicializálására, a tearDown az erőforrások tisztítására szolgál. setUpWithError és tearDownWithError lehetővé teszik az inicializálási hibák kezelését try-catch nélkül minden tesztben.

Minden metódus, amelynek neve `test`-tel kezdődik, automatikusan tesztként kerül felismerésre az Xcode-ban. Alternatívaként a `@Test` makró (Swift Testing) is használható. A teszt nevének leírónak kell lennie: `testLoginWithValidCredentials` jobb, mint `testLogin1`. Dokumentálás a tesztek kommentekkel történő ellátása jó gyakorlat, de az Xcode lehetővé teszi a leírás hozzáadását User-Defined Attributes segítségével.

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")
    }
}

A fenti példa az XCTestCase szabványos szerkezetét mutatja be. sut (System Under Test) — a tesztelt objektum elnevezési konvenciója. A MockURLSession helyettesíti a valós hálózatot, lehetővé téve a UserService elkülönített tesztelését. Az "egy teszt — egy ellenőrzés" elv leegyszerűsíti a hibakeresést. Minden XCTestCase tesztnek egy forgatókönyvet vagy egy állítást kell ellenőriznie.

Asszertációk az XCTest-ben

Az asszertációk alapcsoportja

XCTAssertTrue és XCTAssertFalse — alap asszertációk logikai értékek ellenőrzésére. Az XCTAssertTrue(expression) akkor megy át, ha expression == true. Az XCTAssertEqual két érték egyenlőségét ellenőrzi, támogatva minden típust, amely implementálja az Equatable-t. Lebegőpontos számokhoz az XCTAssertEqual accuracy paraméterrel használatos a számítási hiba figyelembevételére. A Google Testing Blog (2024) szerint az XCTAssertEqual a tipikus teszthalmaz összes ellenőrzésének 70%-át fedi le.

Nil asszertációk és hibák

XCTAssertNil és XCTAssertNotNil az opcionális értékeket nil-ra ellenőrzi. Ezek az asszertációk kritikusak a Swift számára, ahol az opcionális típusok széles körben használatosak. Az XCTAssertThrowsError ellenőrzi, hogy a kód dob-e várt hibát. XCTUnwrap — asszertáció, amely kicsomagolja az opcionális értéket, és érthető üzenettel megbukik, ha az érték nil. A stringek összehasonlítása az XCTAssertEqual-lel literális összehasonlítást használ, nem szemantikusat. XCTAssertNoThrow — pár asszertáció annak ellenőrzésére, hogy a kód nem dob hibát.

XCTestExpectation és aszinkron tesztek

XCTestExpectation — mechanizmus az aszinkron kód tesztelésére. A teszt létrehoz egy várakozást leíró névvel, átadja az aszinkron műveletnek és meghívja a `wait(for:timeout:)`-t. Ha a várakozás nem teljesül a timeout alatt, a teszt megbukik. Időtúllépés alapértelmezés szerint 10 másodperc, de gyors műveletekhez 1–3 másodperc beállítása javasolt a teljes tesztidő felgyorsításához.

XCTWaiter — rugalmasabb alternatíva a wait(for:timeout:)-hoz. Az XCTWaiter lehetővé teszi több várakozásra való várakozást, a végrehajtási sorrend beállítását és a timeout-ok programozott kezelését. A wait-tel ellentétben az XCTWaiter `XCTWaiter.Result`-ot ad vissza, amely elemezhető. Delegált XCTWaiterDelegate értesít a várakozási sorrend megsértéséről és a timeout-okról.

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")
}

A példában az XCTestExpectation az aszinkron bejelentkezés tesztelésére szolgál. fulfill() a callback-en belül hívódik meg, jelezve, hogy az aszinkron művelet befejeződött. Ha 3 másodpercen belül a fulfill() nem hívódik meg — a teszt timeout-tal megbukik. A sikeres várakozás után az asszertációk végrehajtódnak az eredmény ellenőrzésére. Több várakozás tömbként adható át, és várható az összes teljesülése.

Teljesítménytesztek az XCTest-tel

measure(metrics:) — az XCTestCase metódusa teljesítménytesztek létrehozásához. A measure-en belüli kódblokk 10-szer egymás után fut le, és az XCTest statisztikákat gyűjt: átlagos idő, medián, szórás. Metrics — a követett metrikák tömbje: XCTClockMetric (idő), XCTMemoryMetric (memória), XCTStorageMetric (lemez) és XCTCPUMetric (processzor). Az Apple WWDC (2024) szerint az XCTCPUMetric-tel végzett teljesítménytesztek hasznosak az algoritmusok regresszióinak felderítésére.

Baseline (alapvonal) a teljesítménytesztekhez az Xcode Test Plan-ben kerül beállításra. Ha a végrehajtási idő meghatározott százalékkal (alapértelmezett 10%) meghaladja a baseline-t, a teszt sikertelennek minősül. A baseline manuálisan frissítésre kerül, miután megerősítést nyert, hogy a teljesítményváltozás várható. Test Plan az Xcode-ban lehetővé teszi a teljesítménytesztek konfigurációk szerinti csoportosítását: debug/release, különböző eszközök, különböző iOS verziók.

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

Ez a teljesítményteszt egy 10000 elemből álló tömb rendezési idejét méri. XCTClockMetric rögzíti a tényleges végrehajtási időt. Ha a rendezési algoritmus megváltoztatása után az idő 10%-kal vagy többel nő, a teszt regressziót jelez. Az XCTest teljesítménytesztek különösen hasznosak: adatfeldolgozó algoritmusokhoz, UI komponensek rendereléséhez, adatbázis-műveletekhez és hálózati kérésekhez.

Tesztek szervezése és CI/CD integráció

A tesztprojekt szerkezete

A tesztprojekt szerkezete az XCTest-ben a következő konvenciót követi: egy tesztfájl osztályonként, külön `<TargetName>Tests` könyvtárba helyezve. A fájlnevek megfelelnek a tesztelt osztályok nevének `Tests` utótaggal: `UserService.swift` → `UserServiceTests.swift`. A Test Targets az Xcode-ban külön vannak konfigurálva az unit-tesztekhez és UI-tesztekhez, lehetővé téve független futtatásukat. Schemes az Xcode-ban a build konfigurációt és a futtatott tesztek halmazát kezelik.

CI/CD integráció

Xcode Cloud és GitHub Actions támogatják az XCTest futtatását `xcodebuild test -scheme App -testPlan SmokeTest` segítségével. A CI pipeline a következőket foglalja magában: build → unit-tesztek futtatása → UI-tesztek futtatása → jelentés közzététele. A JUnit jelentést az `xcodebuild` generálja a `-resultBundlePath` opcióval, és bármely CI eszközbe importálható. Code Coverage — az XCTest beépített funkciója, amely megmutatja, hogy a kód mely sorait fedik le a tesztek. A termelési kód minimális lefedettségi küszöbértéke — 70% a kritikus üzleti logikához.

Xcode Cloud és GitHub Actions támogatják az XCTest futtatását `xcodebuild test -scheme App -testPlan SmokeTest` segítségével. A CI pipeline a következőket foglalja magában: build → unit-tesztek futtatása → UI-tesztek futtatása → jelentés közzététele. JUnit jelentés az `xcodebuild` által generált a `-resultBundlePath` opcióval, és bármely CI eszközbe importálható. A Bitrise és a Jenkins kész lépésekkel rendelkezik az XCTest számára.

Code Coverage — az XCTest beépített funkciója, amely megmutatja, hogy a kód mely sorait fedik le a tesztek. Az Xcode a lefedettséget zölddel (lefedett), pirossal (nem lefedett) és sárgával (részben lefedett) jeleníti meg. Minimális küszöb a termelési kódhoz — 70% a kritikus üzleti logikához. A Google Testing Blog (2024) szerint a 80%-os lefedettség kötelező előírása az összes modulra "üres tesztek" megjelenéséhez vezet, amelyek nem ellenőrzik a logikát, csak végrehajtják a kódot.