Test Doubles — co to je, typy a aplikace

Co jsou Test Doubles?

Test Doubles — je termín z automobilového průmyslu (kaskadér, „dvojník“ pro herce), přenesený do vývoje softwaru. Jako kaskadér nahrazuje herce v nebezpečné scéně, Test Double nahrazuje skutečný komponent v testovacím scénáři. To je nutné, když skutečná závislost není dostupná, je pomalá, nedeterministická nebo má vedlejší účinky.

Koncepce Test Double zahrnuje pět konkrétních typů, z nichž každý řeší svůj vlastní úkol. Meszarosova typologie je kanonická a používá se ve všech moderních průvodcích testováním. Rozdíl mezi typy je ve stupni kontroly a ověření: od jednoduchého vyplnění parametrů (Dummy) až po úplnou kontrolu posloupnosti volání (Mock).

Proč jsou Test Doubles potřebné

Hlavním cílem Test Doubles je izolace testovaného modulu. V mobilním vývoji jsou skutečnými závislostmi API servery, databáze, souborový systém, senzory zařízení, systémové služby (LocationManager, Camera, Bluetooth). Přímé použití těchto komponentů činí testy pomalými, křehkými a závislými na prostředí. Podle Google Testing Blog (2023), dobře izolované unit testy běží v milisekundách, zatímco integrační testy v sekundách a minutách.

Pět typů Test Doubles

Klasifikace Gerard Meszaros zahrnuje pět typů Test Doubles, které se liší chováním a účelem použití. Porozumění rozdílům mezi nimi je základem správného unit testování.

Dummy

Dummy — je objekt předaný testované metodě, který ale nikdy není použit. Dummy je potřebný jen pro splnění signatury metody. V Kotlin je to často null, emptyList() nebo objekt s náhradami. Dummy by neměl obsahovat žádnou logiku — pokud je zavolán, test by měl selhat.

Fake

Fake — je zjednodušená, ale funkční implementace rozhraní. Na rozdíl od Mock a Stub, Fake obsahuje skutečnou business logiku, ale ve zjednodušené formě. Klasický příklad — InMemoryUserRepository, který ukládá data v HashMap místo databáze. Fake se používá, když je třeba testovat logiku závislou na stavu, ale bez režie skutečné infrastruktury.

Stub

Stub vrací předem dané hodnoty na konkrétní volání. Stub nekontroluje, zda byl zavolán — jednoduše poskytuje data. V Mockito se Stub vytváří přes when(method).thenReturn(value). Stub je ideální pro testování, když závislost musí vrátit konkrétní hodnotu, ale samotný fakt volání není důležitý.

Spy

Spy — je obal kolem skutečného objektu, který zaznamenává všechna volání pro pozdější ověření. Na rozdíl od Mock, Spy deleguje volání na skutečný objekt, ale umožňuje ověřit, že k nim došlo. V Mockito se Spy vytváří přes spy(realObject). Spy je užitečný pro částečné mockování, když chcete použít skutečný objekt, ale ověřit některá volání.

Mock

Mock — je objekt s předdefinovanými očekáváními volání. Mock kontroluje, zda byly určité metody zavolány s určitými argumenty a v určitém pořadí. Na rozdíl od Stub, Mock se zaměřuje na ověření chování, nikoli na vracení dat. Mock je nejsilnější a nejčastěji používaný typ Test Double v mobilním vývoji.

Mock a Stub: klíčové rozdíly

Rozdíl mezi Mock a Stub často způsobuje zmatek i mezi zkušenými vývojáři. Hlavní rozdíl je v účelu: Stub kontroluje stav (state verification), Mock kontroluje chování (behavior verification).

Stub odpovídá na otázku: „vrátil kód správný výsledek?“. Mock odpovídá na otázku: „zavolal kód správné metody se správnými argumenty?“. V mobilním vývoji se Stub používá, když je důležitý výsledek (např. data z repozitáře), a Mock, když jsou důležité vedlejší účinky (např. odeslání emailu, zápis do databáze).

// Stub: kontrola stavu
every { repository.getUsers() } returns listOf(user)
val result = useCase.getUsers()
assertEquals(1, result.size)

// Mock: kontrola chování
every { analytics.logEvent("purchase") } returns Unit
useCase.purchase(item)
verify { analytics.logEvent("purchase") }

Příklady Test Doubles v Kotlin

Praktické příklady všech pěti typů Test Doubles v Kotlin s použitím MockK — nejpopulárnější knihovny mocking pro Android projekty.

Fake: InMemoryUserRepository

class InMemoryUserRepository : UserRepository {
    private val store = mutableMapOf<String, User>()

    override fun save(user: User) {
        store[user.email] = user
    }

    override fun findByEmail(email: String): User? {
        return store[email]
    }
}

Stub + Mock: test UseCase

class RegisterUseCaseTest {
    private val api = mockk<AuthApi>()
    private val repo = spyk(InMemoryUserRepository())
    private val useCase = RegisterUseCase(api, repo)

    fun `register user successfully`() = runTest {
        // Stub: vrácení pevné odpovědi API
        coEvery { api.register("test@test.com") } returns AuthResult.Success("token123")

        val result = useCase.execute("test@test.com")

        // Verify: kontrola, že uživatel byl uložen
        verify { repo.save(any()) }
        assertTrue(result.isSuccess())
    }
}

Dummy: test s nepoužitým parametrem

data class Logger(val appContext: Context, val format: FormatType)

fun `test logger with dummy context`() {
    // Dummy: Context není uvnitř Logger použit
    val dummyContext = mockk<Context>()
    val logger = Logger(dummyContext, FormatType.JSON)
    assertEquals(FormatType.JSON, logger.format)
}

Kdy který typ použít v mobilním vývoji

Výběr typu Test Double závisí na tom, co přesně se testuje: stav, chování nebo integrace. V mobilním vývoji na Android a iOS se vytvořila následující doporučení.

Pro ViewModel a UseCase

Při testování ViewModel použijte Mock pro závislosti, které způsobují vedlejší účinky (repozitáře, analytika, navigace), a Stub pro závislosti, které vracejí data (API klienti, ContentProvider). To umožňuje ověřit, že Viewmodel správně zpracovává úspěšné i chybové scénáře.

Pro Repository a Datovou vrstvu

Na úrovni Repository jsou preferovány Fake (implementace databáze in-memory) a Stub (pevné odpovědi API). Fake umožňuje testovat logiku cache a offline režimu bez konfigurace SQLite. Stub simuluje různé HTTP statusy: 200, 404, 500, timeout.

• Unit testy business logiky — Mock pro všechny externí závislosti, Dummy pro nepoužité parametry
• Integrační testy — Fake místo Mock (ověřujeme, že komponenty spolupracují)
• UI testy — Stub pro API odpovědi (přes MockWebServer nebo WireMock)
• Testy cache — Fake pro databázi (in-memory místo Room/SQLite)
• Testy asynchronnosti — Mock s podporou korutin (MockK + Turbine pro Flow)

Typické chyby při použití náhrad

Nesprávné použití Test Doubles — jeden z nejčastějších důvodů křehkých testů, které se při každém refaktorování rozbijí.

Over-mocking: nadměrné používání Mock

Nejčastější chyba — mockování všeho. Pokud je každá závislost v testu nahrazena Mockem, test přestává kontrolovat skutečné chování. Mock by měl být pouze pro externí závislosti (síť, databáze, souborový systém, systémové služby). Vnitřní komponenty aplikace (Value Object, data class, jednoduché utility) by neměly být nahrazovány.

Under-specification: nedostatečná specifikace

Druhá chyba — vytvoření Mock bez definice očekávání. Pokud je metoda zavolána bez every / when, Mock vrátí výchozí hodnotu (null, 0, false). To může vést k falešně pozitivním testům, když Mock tiše vrátí null a test to interpretuje jako správné chování.

Over-verification: nadměrné ověřování

Třetí chyba — kontrola každého volání každého Mocku. Verify by měl být použit pouze pro volání kritická z hlediska business logiky. Nadměrné ověřování činí testy křehkými: změna pořadí volání v produkčním kódu rozbíjí testy bez změny chování.