Stub: bu nima, turlari va testda qo'llanilishi

Stub nima va boshqa test dublörlaridan qanday farq qiladi?

Stub — bu testda real bog'liqlikni almashtiradigan va ma'lum chaqiruvlarga oldindan belgilangan qiymatlarni qaytaradigan obyekt-zastuplka. Bu atama Gerard Meszaros (2007) tomonidan „xUnit Test Patterns" kitobida tasnifga kiritilgan. Stub test dublörlari — test paytida real komponentlarni almashtiradigan obyektlar toifasiga kiradi. Stubning asosiy maqsadi tashqi tizimlarning noaniqligini bartaraf etib, test qilinadigan blokni bashorat qilinadigan ma'lumotlar bilan ta'minlashdir.

Ishlash prinsipi — test bajarilishidan oldin stublarni konfiguratsiya qiladi: „getUsers() metodi chaqirilganda, ushbu foydalanuvchilar ro'yxatini qaytar". Stub biznes mantig'ini o'z ichiga olmaydi, chaqiruvlar tartibini tekshirmaydi va murojaatlar tarixini yozmaydi. U shunchaki real komponent o'rnida turadi va unga aytilgan narsani qaytaradi. Android testi kontekstida bu OkHttp mijozi serverga real so'rov yubormasligini, balki stub sifatida sozlangan MockWebServer dan javob olishini anglatadi.

• Stub — ma'lumot qaytaradi, chaqiruvlarni tekshirmaydi
• Mock — ma'lumot qaytaradi va xatti-harakatni tekshiradi (verify)
• Fake — real mantiq bilan ishlaydigan soddalashtirilgan implementatsiya
• Spy — real obyekti o'rab, chaqiruvlarni qayd qiladi
• Dummy — uzatiladi, lekin ishlatilmaydi (null, bo'sh obyekt)

Qachon ishlatish kerak — stublar UI qatlami (ViewModel, Presenter) va biznes mantig'ini (UseCase, Interactor) test qilish uchun optimaldir, bunda aniq ma'lumotlarga reaksiyani tekshirish kerak: ro'yxat bo'sh, server 500 xatosi qaytardi, token muddati o'tdi. Test ma'lum kirish holatini talab qiladigan har bir holat stub uchun vazifadir. Har bir test stsenariysi uchun o'z stub konfiguratsiyasi yaratiladi, bu testlarni o'qishli va bashorat qilinadigan qiladi.

Meszaros bo'yicha test dublörlarining tasnifi

Gerard Meszaros (2007) „xUnit Test Patterns" kitobida test dublörlarining besh turini ajratgan: dummy, stub, spy, mock, fake. Har bir tur o'z vazifasini hal qiladi. Dummy — uzatiladi, lekin ishlatilmaydi. Stub — ma'lumot qaytaradi. Spy — chaqiruvlarni qayd qiladi. Mock — xatti-harakatni tekshiradi. Fake — soddalashtirilgan mantiqni o'z ichiga oladi. Ushbu tasnifni tushunish dasturchiga har bir test stsenariysi uchun to'g'ri vositani tanlashga yordam beradi.

Mobil ilovalarni test qilishda stublar qayerda ishlatiladi

Tarmoq so'rovlari uchun stublar

Tarmoq so'rovlari — stublarning eng ko'p ishlatiladigan stsenariysi. Ilova API ga HTTP chaqiruvlarini amalga oshiradi va testda turli javoblarga reaksiyani tekshirish kerak: muvaffaqiyatli JSON, 401 xatosi (ruxsatsiz), vaqt tugashi, bo'sh massiv. Android da MockWebServer (OkHttp) va iOS da URLProtocol stublar rolini o'ynab, real serverga ulanmasdan oldindan belgilangan HTTP javoblarini qaytaradi. Bu testlarni soniyalardan millisoniyalargacha tezlashtiradi.

Ma'lumotlar bazasi — Room (Android) va CoreData (iOS) in-memory variantlariga ega, ammo ularni sozlash baribir vaqt talab qiladi. Stub repository o'rniga MB ga tegmasdan oldindan tayyorlangan Entity ro'yxatlarini qaytaradi. Bu ayniqsa ViewModel ni test qilish uchun samarali, bunda saralash, filtrlash yoki ma'lumot transformatsiyasini tekshirish kerak. Test ma'lumotlar hajmidan qat'iy nazar millisoniyalar ichida bajariladi.

Tizim xizmatlari — LocationManager, SensorManager, SharedPreferences real qurilma yoki emulyator talab qiladi. LocationProvider uchun stub berilgan koordinatalarni, SensorManager uchun — akselerometrning doimiy qiymatlarini qaytaradi. iOS da analog — CLLocationManager test delegate implementatsiyasi bilan. Stublarsiz bunday testlar ma'lum shartlarga ega fizik qurilmani talab qiladi.

Fayl tizimi va kesh — rasmlarni yuklash, javoblarni keshlash, konfiguratsiya fayllari bilan ishlash — bu operatsiyalarning barchasi disk holatiga bog'liq. FileManager yoki ImageCache uchun stub real fayllarni o'qimasdan muvaffaqiyat/xato qaytaradi. Bu turli ishlab chiqaruvchi mashinalarida yo'llar yoki ruxsatlarning mos kelmasligi sababli testlarning soxta ishdan chiqishini bartaraf qiladi.

Stub vs Mock vs Fake: asosiy farqlar

Mas'uliyatlarni taqsimlash — uch turdagi test dublörlari turli vazifalarni hal qiladi. Stub: „menga ma'lumot ber". Mock: „meni chaqirishganini tekshir". Fake: „men real kabi ishlayman, faqat soddaroq". Farq testlarning o'qishliligi uchun juda muhim: agar test stub kerak bo'lgan joyda mock ishlatsa, u test qilinayotgan stsenariy bilan bog'liq bo'lmagan verify chaqiruvlari bilan yuklanadi.

Amaliy qoida — agar test tekshirilayotgan komponent qanday ma'lumot olganini tekshirsa — stub ishlating. Agar test komponent bog'liqlik metodini to'g'ri argumentlar bilan chaqirganini tekshirsa — mock ishlating. Agar shunchaki MB ni hash jadvali bilan almashtirmoqchi bo'lsangiz — bu fake. Bir testda turlarni aralashtirish uni mo'rt qiladi: implementatsiya o'zgarganda ham stub, ham verify mantig'ini qayta yozishga to'g'ri keladi.

Antipattern: verify bilan Stub

Verify bilan Stub — dasturchi stublarni konfiguratsiya qilib, keyin verify(stub).method() qo'shganda keng tarqalgan xato. Stub ta'rifiga ko'ra tasdiqlanmasligi kerak — tasdiqlash uchun mock mavjud. Agar metodning aniq argumentlar bilan chaqirilganligini tekshirish kerak bo'lsa, Mockito.stub() o'rniga Mockito.mock() ishlating. Bu bo'linish testning maqsadini boshqa dasturchilar uchun aniq saqlaydi.

Android da MockWebServer va MockK bilan stublarni amalga oshirish

MockWebServer — Android va JVM da HTTP stublari yaratish uchun OkHttp kutubxonasi. U belgilangan portda mahalliy HTTP serverini ishga tushiradi, OkHttp mijozining so'rovlarini tutib oladi va oldindan belgilangan javoblarni qaytaradi. Sozlash uch qatorni oladi: server yaratish, javobni navbatga qo'yish (enqueue), ishga tushirish. Test paginatsiya yoki qayta urinishlar stsenariylari uchun ketma-ket bir nechta javobni navbatga qo'yishi mumkin.

class UserRepositoryTest {

    private val server = MockWebServer()

    fun setup() {
        server.start(8080)
        val client = OkHttpClient.Builder()
            .readTimeout(1, TimeUnit.SECONDS)
            .build()
    }

    fun test_user_list_success() {
        val json = "[{\"id\":1,\"name\":\"Alice\"}]"
        server.enqueue(MockResponse()
            .setBody(json)
            .setResponseCode(200)
        )
        val result = repository.getUsers()
        assertEquals(1, result.size)
    }

    fun teardown() {
        server.shutdown()
    }
}

MockK — Kotlin uchun Mockito ga alternativ, korutinlar, kengaytma funksiyalar va sealed sinflar uchun first-class qo'llab-quvvatlash bilan. MockK da stublar coEvery (suspend funksiyalar uchun) va every (odatiy funksiyalar uchun) orqali yaratiladi. MockWebServer dan farqli o'laroq, MockK butun HTTP qatlamini emas, balki alohida bog'liqlik metodlarini almashtiradi. Bu bog'liqliklari repository abstraksiyalari bo'lgan UseCase yoki Interactor unit testlari uchun qulaydir.

interface UserRepository {
    suspend fun getUsers(): List<User>
}

class GetUsersUseCaseTest {

    private val repo = mockk<UserRepository>()

    private val useCase = GetUsersUseCase(repo)

    fun test_empty_list() = runTest {
        coEvery { repo.getUsers() } returns emptyList()

        val result = useCase.invoke()

        assertTrue(result.isEmpty())
        coVerify(exactly = 1) { repo.getUsers() }
    }
}

Best practice — integratsiya testlari uchun MockWebServer dan foydalaning (real HTTP ni tutib oladi), unit testlari uchun — MockK (interfeyslarni almashtiradi). Siz test qilmayotgan narsani almashtirmang: agar test Repository ni tekshirsa, uning ichidagi OkHttp mijozini almashtirmang — HTTP darajasida haqiqiy MockWebServer dan foydalaning. Bu qoida testlarni dolzarb saqlaydi va refaktoring paytida mo'rtlikni kamaytiradi.

iOS da OCMock va protokollar bilan stublarni amalga oshirish

Swift protokollari stublar sifatida — iOS-native yondashuvda stub bog'liqlik protokoli ga mos keladigan test strukturasini joylashtirish orqali amalga oshiriladi. Haqiqiy NetworkService o'rniga test StubNetworkService oladi, u doimiy ma'lumotlarni qaytaradi. Swift statik tipli til, shuning uchun stub haqiqiy xizmat bilan bir xil protokolga mos kelishi kerak. Kompilyator stub barcha talab qilinadigan metodlarni implementatsiya qilishini kafolatlaydi.

protocol NetworkServiceProtocol {
    func fetchUsers() async throws -> [User]
}

struct StubNetworkService: NetworkServiceProtocol {
    let result: Result<[User], Error>

    func fetchUsers() async throws -> [User] {
        try result.get()
    }
}

final class UsersViewModelTests: XCTestCase {
    func test_success_state() async {
        let stub = StubNetworkService(
            result: .success([User(name: "Alice")])
        )
        let vm = UsersViewModel(service: stub)
        await vm.load()
        XCTAssertEqual(vm.users.count, 1)
    }
}

Objective-C uchun OCMock — legacy iOS loyihalarida stublar va moklar yaratish uchun kutubxona. OCMock argumentlar va qaytariladigan qiymatlar bilan stub metodlarini qo'llab-quvvatlaydi. Swift da zamonaviy loyihalar qo'lda stublar bilan protokol asosidagi yondashuvni afzal ko'radi — bu har bir metod ustidan nazorat beradi va tashqi bog'liqliklarni talab qilmaydi. OCMock barcha bog'liqliklarni protokollash iqtisodiy jihatdan maqsadga muvofiq bo'lmagan loyihalar uchun variant bo'lib qoladi.

HTTP stublari uchun URLProtocol — URLProtocol ost sinfi orqali tarmoq so'rovlarini tutib olish uchun iOS tizim mexanizmi. Test URLSession ni tutib oladigan va stub javoblarini qaytaradigan maxsus URLProtocol ni ro'yxatdan o'tkazadi. Qo'lda stublardan afzalligi: ilova arxitekturasini o'zgartirish shart emas — URLSession haqiqiy qoladi, lekin ma'lumotlar protokol darajasida almashtiriladi. Kamchiligi: aniq stub xizmatidan ko'ra murakkabroq tuzatiladi (debug).