Mock — ce este, obiectele mock și bibliotecile pentru teste

Ce este Mock?

Mock — este un obiect creat de framework-ul de mocking (Mockito, MockK, EasyMock), care imită o interfață sau o clasă și înregistrează toate apelurile metodelor sale. Dezvoltatorul stabilește așteptări: metoda X va fi apelată cu argumentele Y și va returna Z. După executarea testului, Mock verifică dacă așteptările coincid cu apelurile reale.

Termenul provine din metafora teatrală a Test Doubles: Mock este un „imitator“ care nu doar stă pe scenă (ca Dummy), ci joacă un rol și verifică dacă interacțiunea cu el a fost corectă. Dacă codul testat nu a apelat metoda pe care Mock o aștepta sau a apelat-o cu argumente incorecte — testul eșuează cu un mesaj despre așteptarea încălcată.

Cum funcționează Mock

Mock este creat prin fabrica framework-ului: mockk<MyInterface>() sau Mockito.mock(MyClass.java). Framework-ul generează un obiect proxy care interceptează toate apelurile metodelor. Fiecare apel este comparat cu așteptările (expectations) prestabilite. Dacă apelul corespunde așteptării — se returnează valoarea dată. Dacă nu — Mock returnează o valoare implicită sau aruncă o excepție, în funcție de configurare.

Când este necesar Mock

Mock este obligatoriu când codul testat interacționează cu componente care au efecte secundare: trimiterea datelor pe server, scrierea în baza de date, logare, analitică, navigare, afișarea dialogurilor de sistem. Fără Mock, aceste interacțiuni nu pot fi verificate fără a porni infrastructura reală. Conform Google Testing Blog, Mock este singura modalitate de a verifica că aplicația a trimis într-adevăr un eveniment de analitică fără a porni un server de test.

Mock și Stub: comparație detaliată

Diferența dintre Mock și Stub este unul dintre cele mai discutate subiecte în testare. Ambele tipuri înlocuiesc dependența reală, dar în moduri fundamental diferite.

Regula practică: Mock sau nu

Un test simplu pentru alegere: întrebați-vă — „dacă șterg această linie de cod, va cădea testul?“. Dacă testul verifică valoarea returnată — este necesar Stub (verificare prin assert). Dacă testul verifică dacă codul a apelat metoda cu argumentele corecte — este necesar Mock (verificare prin verify). Această dicotomie urmează din modelul Command-Query Separation: metodele care schimbă starea (commands) au nevoie de Mock; metodele care returnează date (queries) au nevoie de Stub.

Mockito și MockK: comparația bibliotecilor

Alegerea între Mockito și MockK este una dintre primele decizii la configurarea stivei de testare a unui proiect Android în Kotlin. Ambele biblioteci îndeplinesc aceeași sarcină, dar cu o abordare diferită față de specificul Kotlin.

Mockito: clasica dovedită

Mockito — este standardul de facto pentru proiectele Java. Versiunea 5.x suportă obiecte mock pentru clase finale, metode statice și constructori datorită MockMaker-ului încorporat. Pentru proiectele Kotlin, Mockito necesită configurare suplimentară: extensii mockito-kotlin pentru sintaxă îmbunătățită, mockito-inline pentru clase finale. Mockito nu suportă corutinele Kotlin și funcțiile suspend fără adaptoare suplimentare.

MockK: abordarea Kotlin-first

MockK a fost creat special pentru Kotlin. Suportă nativ corutinele (coEvery, coVerify), sealed class, data class, singleton-uri object și funcții de extensie. Sintaxa MockK utilizează DSL cu blocuri lambda, ceea ce arată natural în codul Kotlin. MockK poate, de asemenea, să mock-uiască proprietăți (property mocking) fără configurare suplimentară — acest lucru este important pentru proiectele Android care folosesc LiveData, StateFlow și Delegates.

// Mockito + mockito-kotlin
val repository = mock<UserRepository>()
whenever(repository.getUser(1)).thenReturn(user)

// MockK
val repository = mockk<UserRepository>()
every { repository.getUser(1) } returns user

Compararea performanței

Benchmark-urile (JVM Benchmark, 2024) arată că MockK creează obiecte mock cu 15–20% mai rapid decât Mockito pentru proiectele Kotlin datorită lucrului direct cu bytecode-ul Kotlin, nu cu Java Reflections. Pentru proiectele cu mii de teste unitare, diferența în timpul de construire poate fi vizibilă: MockK economisește 30–60 de secunde la rularea completă a testelor în proiecte mari.

Exemple de teste Mock în Kotlin

Vom examina trei scenarii: testarea ViewModel cu dependențe Mock, testarea UseCase cu verificarea apelului API și testarea corutinelor cu coVerify.

Exemplul 1: ViewModel cu analitică mock-uită

class ProfileViewModelTest {
    private val analytics = mockk<AnalyticsService>()
    private val repo = mockk<UserRepository>()
    private val vm = ProfileViewModel(repo, analytics)

    fun `profile opened logs analytics event`() {
        every { analytics.logEvent("profile_opened") } returns Unit

        vm.onViewCreated()

        verify { analytics.logEvent("profile_opened") }
    }
}

Exemplul 2: UseCase cu verificare asincronă

class SendMessageUseCaseTest {
    private val api = mockk<MessagingApi>()
    private val useCase = SendMessageUseCase(api)

    fun `send message with correct payload`() = runTest {
        val message = Message(text = "Hello", userId = 42)

        coEvery { api.sendMessage(any()) } returns MessageResult.Sent("msg_1")

        val result = useCase.execute(message)

        coVerify {
            api.sendMessage(match {
                it.text == "Hello" && it.userId == 42
            })
        }
        assertTrue(result is MessageResult.Sent)
    }
}

Exemplul 3: verificarea argumentelor cu ArgumentCaptor

class OrderUseCaseTest {
    private val api = mockk<OrderApi>()
    private val useCase = OrderUseCase(api)
    private val slot = slot<OrderRequest>()

    fun `order request contains correct items`() = runTest {
        coEvery { api.placeOrder(capture(slot)) } returns OrderResult.Placed("order_1")

        useCase.execute(listOf("item_a", "item_b"))

        assertEquals(2, slot.captured.items.size)
        assertEquals("item_a", slot.captured.items[0])
    }
}

Cele mai bune practici de testare cu Mock

Utilizarea eficientă a Mock în dezvoltarea mobilă necesită disciplină. Încălcarea acestor reguli transformă testele în obstacole fragile care se strică la fiecare refactorizare.

Mock-uiți doar granițele externe ale aplicației

Regulă strictă: Mock este creat doar pentru dependențele care traversează granița aplicației: clienți API, baze de date, sistemul de fișiere, servicii de sistem (LocationManager, BluetoothAdapter, Camera). Clasele interne ale aplicației — entități de domeniu, Value Object, utilități simple — nu trebuie înlocuite cu Mock. Comportamentul lor se testează prin obiecte reale.

Un assert/verify per test

Fiecare test trebuie să conțină exact o verificare logică — fie verify (pentru Mock), fie assert (pentru Stub). Nu amestecați verificarea stării și a comportamentului într-un singur test. Dacă trebuie verificate atât apelul API, cât și rezultatul — creați două teste separate cu nume diferite. Această regulă, cunoscută ca „un assert per test“, provine din recomandările lui Kent Beck (2002).

• Utilizați relaxUnitFun = true în MockK pentru metodele care returnează Unit — altfel Mock va arunca o excepție la un apel nedescis
• Limitați verify doar la apelurile critice — nu verificați fiecare getter și setter, acest lucru face testele fragile
• Aplicați ArgumentMatchers cu sens — any() ascunde detalii importante dacă argumentul este critic pentru logica de business
• Nu abuzați de verifyNoMoreInteractions — această metodă face testul inutil de rigid la orice schimbare în codul de producție
• Utilizați @MockkAnnotations pentru inițializarea automată a obiectelor Mock — reduce boilerplate-ul și îmbunătățește lizibilitatea

Tehnici avansate de testare cu Mock

Pe lângă mocking-ul de bază, există tehnici avansate care rezolvă sarcini specifice în dezvoltarea mobilă: testarea multi-threading-ului, verificarea stării Flow și mocking-ul parțial al obiectelor reale.

Partial Mock cu spyK

Spy (sau partial mock) permite crearea unui obiect care delegă apelurile către implementarea reală, dar permite supradefinirea metodelor individuale. În MockK, spyk este creat pe baza unei instanțe reale a clasei: val repo = spyk(InMemoryUserRepository()). Apelurile pentru care sunt stabilite așteptări prin every trec prin Mock; restul — prin obiectul real. Spy este deosebit de util pentru testarea codului legacy, unde injectarea dependențelor nu a fost încă implementată și trebuie supradefinită o singură metodă.

Testarea StateFlow cu Turbine

În proiectele moderne Android pe Jetpack Compose, ViewModel expune starea prin StateFlow. MockK permite mock-uirea dependențelor Flow, iar biblioteca Turbine simplifică verificarea emisiei. Modelul clasic: MockK pentru UseCase care returnează Flow, Turbine pentru verificarea emisiei ViewModel. Acest stack este recomandat de documentația Android Testing (Google, 2024) pentru proiectele pe Kotlin Coroutines.

class SearchViewModelTest {
    private val searchUseCase = mockk<SearchUseCase>()
    private val vm = SearchViewModel(searchUseCase)

    fun `search emits results`() = runTest {
        coEvery { searchUseCase.search("android") } returns
            flowOf(SearchResult.Success(listOf(Item("Android TDD"))))

        vm.search("android")

        vm.state.test {
            val state = awaitItem()
            assertTrue(state.items.isNotEmpty())
            cancelAndIgnoreRemainingEvents()
        }
    }
}