Integrační testování v mobilním vývoji — podstata, typy a jak se provádí

Co je integrační testování?

Integrační testování — je fáze ověřování softwaru, při které se hodnotí správnost interakce mezi jednotlivými moduly nebo subsystémy aplikace. Zatímco jednotkové testy kontrolují každou komponentu izolovaně, integrační testy tyto komponenty spojují dohromady a ověřují, jak fungují ve spojení. Typické scénáře zahrnují přenos dat mezi síťovou vrstvou a úložištěm, zápis do databáze přes ORM a zpracování odpovědí z API třetích stran.

V kontextu mobilního vývoje integrační testy pokrývají interakci mezi UI vrstvou, obchodní logikou a zdroji dat. Například test může ověřit, že po stisknutí tlačítka „Přihlásit se“ aplikace odešle požadavek na server, obdrží token a uloží jej do lokálního úložiště. Taková kontrola potvrzuje, že řetězec komponent funguje bez selhání.

Podle zprávy World Quality Report 2023 společnosti, které pravidelně aplikují integrační testování, snižují počet produkčních incidentů o 35% ve srovnání s projekty spoléhajícími se pouze na jednotkové testy. To činí integrační kontroly povinným prvkem strategie zajišťování kvality v komerčním vývoji.

Proč je integrační testování v mobilních aplikacích důležité

Mobilní aplikace se skládají z mnoha vzájemně propojených komponent: síťových požadavků, lokálních databází, push notifikací, systémových služeb a SDK třetích stran. Každá z těchto komponent je vyvíjena samostatně, ale za běhu si vyměňují data v reálném čase. Integrační testování odhaluje defekty, které nelze odhalit při izolované kontrole modulů.

Mezi typické problémy odhalené integračními testy patří nesoulad datových typů mezi API a modelem aplikace, chyby serializace JSON, nesprávné zpracování síťových časových limitů a selhání při paralelním přístupu k databázi přes Room nebo Core Data. Bez integračních kontrol se takové defekty dostanou do produkce a projeví se pouze u skutečných uživatelů.

Výzkum Google Testing Blog (2021) ukazuje, že náklady na opravu defektu odhaleného ve fázi integračního testování jsou 5krát nižší než po vydání. Je to proto, že v raných fázích má vývojář úplný kontext chyby a může ji opravit bez urgentního hotfix cyklu. Investice času do psaní integračních testů se vyplácí snížením nákladů na údržbu a zvýšením důvěry uživatelů.

Přístupy k integračnímu testování

Existují tři hlavní přístupy k organizaci integračních testů: Big Bang, Bottom-Up a Top-Down. Volba strategie závisí na velikosti projektu, architektuře aplikace a dostupnosti komponent v době psaní testů. Každý přístup má své výhody a omezení, které je důležité zvážit při plánování testovacího pokrytí.

Big Bang

Big Bang — přístup, při kterém jsou všechny komponenty systému propojeny současně, poté je proveden celkový testovací běh. Tato metoda je jednoduchá na implementaci: nevyžaduje psaní stubů ani emulaci jednotlivých modulů. Při odhalení chyby je však obtížné určit, která komponenta je jejím zdrojem. Big Bang je opodstatněný v malých projektech s jednoduchou architekturou, kde počet modulů nepřesahuje pět.

Bottom-Up

Bottom-Up — strategie, při které integrační testování začíná od nízkoúrovňových komponent: databáze, síťové vrstvy, systémových služeb. Po kontrole každé úrovně testy postupně připojují vyšší moduly — úložiště, Use Case třídy a ViewModel. Hlavní výhodou je včasné odhalení defektů v základních vrstvách aplikace, což snižuje riziko kaskádových chyb v pozdějších fázích vývoje.

Top-Down

Top-Down — přístup, při kterém testování začíná od komponent horní úrovně — UI obrazovek a navigace, zatímco nižší moduly jsou imitovány pomocí stubů nebo mocků. To umožňuje kontrolovat uživatelské scénáře dříve, než je plně implementována serverová část nebo databáze. Top-Down je zvláště užitečný při paralelním vývoji klientské a serverové části, když backend ještě není připraven k reálné integraci.

Nástroje pro integrační testování

Pro integrační testování mobilních aplikací se používá řada specializovaných nástrojů, které se dělí do tří kategorií: knihovny pro emulaci serverů, frameworky pro práci s databázemi a prostředky pro kontrolu systémových služeb. Volba konkrétního nástroje závisí na platformě — Android nebo iOS — a technologickém stacku projektu.

• MockWebServer — knihovna Square pro Android emulující HTTP server v testovacím prostředí. Umožňuje nastavit očekávané odpovědi, kontrolovat tělo a hlavičky požadavků, simulovat síťové chyby.
• OHHTTPStubs — knihovna pro iOS zachycující síťové požadavky na úrovni NSURLProtocol a vracející předem připravené odpovědi. Podporuje zpoždění a chyby připojení.
• Room Testing — vestavěný mechanismus Androidu pro testování databáze: vytvoření in-memory instance Room, provádění operací zápisu a čtení, kontrola migrací a triggerů.
• Core Data Testing — přístup pro iOS, při kterém se vytvoří in-memory kontejner Core Data, umožňující testovat dotazy, vztahy mezi entitami a ukládání dat bez trvalého úložiště.

Příklady kódu pro integrační testy

Podívejme se na praktické příklady integračních testů pro Android a iOS. Pro platformu Android používáme MockWebServer ve spojení s JUnit, pro iOS — XCTest s knihovnou OHHTTPStubs. Oba příklady kontrolují scénář získání dat z API a jejich uložení v lokálním úložišti.

Android: testování síťové vrstvy s MockWebServer

Tento test ověřuje, že Retrofit požadavek na emulovaný server vrací správný JSON a úložiště převádí odpověď na doménový model. MockWebServer zachycuje požadavek a vrací zadaný JSON, poté test porovná očekávaný výsledek se skutečným.

class UserRepositoryTest {
    private val mockServer = MockWebServer()

    @Before
    fun setup() {
        mockServer.start()
    }

    @Test
    fun fetchUser_returnsCorrectData() {
        val json = "{ \`"id\`": 1, \`"name\`": \`"Alice\`" }"
        mockServer.enqueue(MockResponse()
            .setBody(json)
            .setResponseCode(200))

        val repository = UserRepository(
            createRetrofit(mockServer.url("/").toString()))
        val user = repository.fetchUser(1)

        assertEquals(1, user.id)
        assertEquals("Alice", user.name)
    }

    @After
    fun tearDown() {
        mockServer.shutdown()
    }
}

iOS: testování API požadavků s OHHTTPStubs

Pro iOS používá podobný test OHHTTPStubs k zachycení URL požadavků. Knihovna nahrazuje odpověď serveru na úrovni systémového frameworku URL Loading System, což umožňuje testovat libovolnou síťovou knihovnu — URLSession, Alamofire nebo Moya.

import XCTest
import OHHTTPStubs
import OHHTTPStubsSwift

class UserRepositoryTests: XCTestCase {
    func testFetchUser_returnsCorrectData() {
        stub(condition: isPath("/users/1")) { _ in
            return HTTPStubsResponse(
                jsonObject: ["id": 1, "name": "Alice"],
                statusCode: 200,
                headers: nil
            )
        }

        let repository = UserRepository()
        let expectation = expectation(description: "fetch user")

        repository.fetchUser(id: 1) { user in
            XCTAssertEqual(user.id, 1)
            XCTAssertEqual(user.name, "Alice")
            expectation.fulfill()
        }

        waitForExpectations(timeout: 2.0)
    }
}

Nejlepší postupy integračního testování

Efektivní integrační testování vyžaduje dodržování řady postupů, které zvyšují stabilitu testů a snižují náklady na jejich údržbu. Izolujte externí závislosti: používejte in-memory databáze místo produkčních instancí a emulujte externí API pomocí knihoven testovacích stubů. To eliminuje nedeterministická selhání způsobená dostupností sítě nebo stavem externích služeb.

Udržujte nezávislost testů: každý integrační test musí pracovat izolovaně, bez závislosti na výsledcích jiných testů. Používejte anotace @Before a @After v JUnit nebo setUp a tearDown v XCTest pro přípravu a čištění testovacího prostředí. To zabraňuje vzájemnému ovlivňování testů a zjednodušuje diagnostiku chyb.

Pokrývejte okrajové případy: integrační testy by měly kontrolovat nejen úspěšné scénáře (happy path), ale také zpracování chyb — časové limity, HTTP kódy 4xx a 5xx, prázdné odpovědi, poškozený JSON. Podle údajů Google Testing Blog (2022) souvisí 60% produkčních incidentů s nesprávným zpracováním okrajových případů, které nebyly pokryty testy.