Test Doubles — vad är det, typer och tillämpning

Vad är Test Doubles?

Test Doubles — är en term från bilindustrin (stuntman, “double” för skådespelare), överförd till mjukvaruutveckling. Precis som en stuntman ersätter en skådespelare i en farlig scen, ersätter Test Double en verklig komponent i ett testscenario. Detta är nödvändigt när det verkliga beroendet inte är tillgängligt, är långsamt, icke-deterministiskt eller har biverkningar.

Konceptet Test Double omfattar fem specifika typer, var och en med sin egen uppgift. Meszaros typologi är kanonisk och används i alla moderna testningsguider. Skillnaden mellan typerna ligger i graden av kontroll och verifiering: från enkel parameterifyllnad (Dummy) till fullständig kontroll av anropssekvensen (Mock).

Varför Test Doubles behövs

Huvudsyftet med Test Doubles är isolering av den testade modulen. I mobil utveckling är verkliga beroenden API-servrar, databaser, filsystem, enhetssensorer, systemtjänster (LocationManager, Camera, Bluetooth). Direkt användning av dessa komponenter gör testerna långsamma, bräckliga och beroende av omgivningen. Enligt Google Testing Blog (2023) körs välisolerade enhetstester på millisekunder, medan integrationstester tar sekunder och minuter.

Fem typer av Test Doubles

Klassificeringen av Gerard Meszaros omfattar fem typer av Test Doubles, som skiljer sig åt i beteende och användningssyfte. Att förstå skillnaderna mellan dem är grunden för korrekt enhetstestning.

Dummy

Dummy — är ett objekt som skickas till den testade metoden men aldrig används. Dummy behövs bara för att uppfylla metodens signatur. I Kotlin är detta ofta null, emptyList() eller ett objekt med ersättningar. Dummy bör inte innehålla någon logik — om det anropas bör testet misslyckas.

Fake

Fake — är en förenklad men fungerande implementering av ett gränssnitt. Till skillnad från Mock och Stub innehåller Fake verklig affärslogik, men i förenklad form. Det klassiska exemplet — InMemoryUserRepository, som lagrar data i HashMap istället för i en databas. Fake används när logik som beror på tillstånd behöver testas, men utan overhead av verklig infrastruktur.

Stub

Stub returnerar förbestämda värden på specifika anrop. Stub kontrollerar inte om det anropats — det bara tillhandahåller data. I Mockito skapas Stub via when(method).thenReturn(value). Stub är idealisk för testning när beroendet måste returnera ett specifikt värde, men själva faktumet att det anropas är inte viktigt.

Spy

Spy — är ett omslag runt ett verkligt objekt som registrerar alla anrop för senare verifiering. Till skillnad från Mock, delegerar Spy anrop till det verkliga objektet, men gör det möjligt att kontrollera att de inträffade. I Mockito skapas Spy via spy(realObject). Spy är användbart för partiell mockning när du vill använda ett verkligt objekt men kontrollera vissa anrop.

Mock

Mock — är ett objekt med fördefinierade anropsförväntningar. Mock kontrollerar om specifika metoder anropats med specifika argument och i en specifik ordning. Till skillnad från Stub fokuserar Mock på beteendeverifiering, inte på att returnera data. Mock är den kraftfullaste och mest använda typen av Test Double i mobil utveckling.

Mock och Stub: viktiga skillnader

Skillnaden mellan Mock och Stub orsakar ofta förvirring även bland erfarna utvecklare. Huvudskillnaden ligger i syftet: Stub kontrollerar tillstånd (state verification), Mock kontrollerar beteende (behavior verification).

Stub svarar på frågan: “returnerade koden rätt resultat?”. Mock svarar på frågan: “anropade koden rätt metoder med rätt argument?”. I mobil utveckling används Stub när resultatet är viktigt (t.ex. data från ett repository), och Mock när biverkningar är viktiga (t.ex. skicka e-post, skriva till databas).

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

// Mock: beteendekontroll
every { analytics.logEvent("purchase") } returns Unit
useCase.purchase(item)
verify { analytics.logEvent("purchase") }

Exempel på Test Doubles i Kotlin

Praktiska exempel på alla fem typer av Test Doubles i Kotlin med användning av MockK — det mest populära mocking-biblioteket för Android-projekt.

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: UseCase-test

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

    fun `register user successfully`() = runTest {
        // Stub: returnera fast API-svar
        coEvery { api.register("test@test.com") } returns AuthResult.Success("token123")

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

        // Verify: kontrollera att användaren har sparats
        verify { repo.save(any()) }
        assertTrue(result.isSuccess())
    }
}

Dummy: test med oanvänd parameter

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

fun `test logger with dummy context`() {
    // Dummy: Context används inte inom Logger
    val dummyContext = mockk<Context>()
    val logger = Logger(dummyContext, FormatType.JSON)
    assertEquals(FormatType.JSON, logger.format)
}

När ska vilken typ användas i mobil utveckling

Valet av Test Double-typ beror på vad som exakt testas: tillstånd, beteende eller integration. I mobil utveckling på Android och iOS har följande rekommendationer bildats.

För ViewModel och UseCase

Vid testning av ViewModel, använd Mock för beroenden som orsakar biverkningar (repositoryn, analys, navigering) och Stub för beroenden som returnerar data (API-klienter, ContentProvider). Detta gör det möjligt att kontrollera att ViewModel korrekt hanterar både lyckade och felaktiga scenarier.

För Repository och Datalager

På Repository-nivå föredras Fake (in-memory databasimplementeringar) och Stub (fasta API-svar). Fake möjliggör testning av cache-logik och offline-läge utan konfiguration av SQLite. Stub simulerar olika HTTP-statusar: 200, 404, 500, timeout.

• Enhetstester av affärslogik — Mock för alla externa beroenden, Dummy för oanvända parametrar
• Integrationstester — Fake istället för Mock (kontrollera att komponenter fungerar tillsammans)
• UI-tester — Stub för API-svar (via MockWebServer eller WireMock)
• Cache-tester — Fake för databas (in-memory istället för Room/SQLite)
• Asynkrona tester — Mock med stöd för korutiner (MockK + Turbine för Flow)

Vanliga misstag vid användning av ersättningar

Felaktig användning av Test Doubles — en av de vanligaste orsakerna till bräckliga tester som går sönder vid varje omfaktorering.

Over-mocking: överdriven användning av Mock

Det vanligaste misstaget — att mocka allt. Om varje beroende i ett test är ersatt med Mock, slutar testet att kontrollera verkligt beteende. Mock bör endast vara för externa beroenden (nätverk, databas, filsystem, systemtjänster). Interna komponenter i applikationen (Value Object, data class, enkla verktyg) bör inte ersättas.

Under-specification: otillräcklig specifikation

Det andra misstaget — att skapa en Mock utan att definiera förväntningar. Om en metod anropas utan every / when, returnerar Mock ett standardvärde (null, 0, false). Detta kan leda till falskt positiva tester när Mock tyst returnerar null och testet tolkar detta som korrekt beteende.

Over-verification: överdriven verifiering

Det tredje misstaget — att kontrollera varje anrop av varje Mock. Verify bör endast användas för anrop som är kritiska ur affärslogikens synvinkel. Överdriven verifiering gör tester bräckliga: ändring av anropsordningen i produktionskod bryter tester utan att ändra beteendet.