Fake — nima, maqsadi va testlashda qanday foydalanish

Fake nima va testlashda nima uchun kerak?

Fake — to‘liq, ammo yengil interfeys implementatsiyasi bo‘lib, testlash uchun mos keladi. Termin Gerard Meszaros (2007) tomonidan «xUnit Test Patterns» kitobida kiritilgan. Qattiq belgilangan javoblarni qaytaradigan stub-dan farqli o‘laroq, fake bajariladigan kodni o‘z ichiga oladi: ro‘yxatni saralashi, shart bo‘yicha filtrlashi, yozuvlar sonini hisoblashi mumkin. Ishlab chiqarish implementatsiyasidan yagona farq — fake in-memory ma’lumotlar bilan ishlaydi va real I/O operatsiyalarini bajarmaydi.

Asosiy afzallik — tezlik. Fake bilan testlar millisekundlarda bajariladi, chunki diskka, tarmoqqa yoki ma’lumotlar bazasiga murojaat yo‘q. In-memory HashMap Room yoki CoreData-dan 100-1000 marta tez ishlaydi. Shu bilan birga fake real biznes mantiqni tekshiradi: saralash, filtrlash, agregatsiya — stub tekshira olmaydigan hamma narsa, chunki stub faqat unga aytilgan narsani qaytaradi. Fake kod ma’lumotlarni to‘g‘ri qayta ishlayotganiga ishonch beradi, shunchaki oldindan belgilangan javobni olmaydi.

Fake qachon Stub-dan afzal

Fake Stub-dan afzal — agar test qilinayotgan komponent ma’lumotlar ustida bir nechta operatsiyalarni bajarilsa (chiqardi, filtrladi, saraladi, saqladi), stub har bir chaqiruvni alohida sozlashni talab qiladi. Fake mantiqni o‘z ichida saqlaydi — test shunchaki metodlarni chaqiradi va natijani tekshiradi. IT Sectr-da biz unit testlarda barcha repozitoriyalar uchun fake-dan foydalanamiz: HashMap bilan fake-repozitoriya Mockito yoki MockK sozlamasisiz %90 stsenariylarni qamrab oladi.

Fake vs Stub vs Mock: qachon nimani tanlash

Tanlash mezoni — test nimani tekshirishini aniqlang: holatni yoki o‘zaro ta‘sirni. Agar test holatni (ish natijasini) tekshirsa va mantiqdan foydalansa — fake kerak. Agar testga faqat mantiqsiz kirish ma’lumotlari kerak bo‘lsa — stub yetarli. Agar test metod chaqirilganligini tekshirsa — mock kerak. Bitta testda test doubles turlarini aralashtirish tushunishni qiyinlashtiradi va mo‘rtlikni oshiradi.

Anti-naqsh: Fake bo‘lmagan Fake — dasturchi aslida stub yoki mock bo‘lgan obyektni fake deb atashi keng tarqalgan xato. Agar InMemoryUserRepository mantiq (filtrlash, saralash) o‘z ichiga olmasa — bu fake emas, in-memory saqlashga ega stub-dir. Fake stub-dan aynan bajariladigan mantiqqa ega bo‘lishi bilan farqlanadi. Agar fake-repozitoriya shunchaki ichiga qo‘yilgan narsani qaytarsa va ma’lumotlarni qayta ishlamasa — mock yoki stub-dan foydalaning.

Test double tanlashning amaliy qoidasi

Amaliy tavsiya — har bir repozitoriya yoki xizmat uchun fake bilan boshlang. Agar fake 50 qatordan murakkab bo‘lsa — bir nechta sinflarga bo‘ling. Agar fake umuman kerak bo‘lmasa (test faqat bitta stsenariyni sobit ma’lumotlar bilan tekshiradi) — stub-dan foydalaning. Agar test metodning ma’lum parametrlar bilan chaqirilganligini tekshirsa — mock-dan foydalaning. Tanlovni oldindan optimallashtirmang: fake yozing, agar ortiqcha bo‘lib chiqsa, aniq testda uni stub bilan almashtiring.

Android-da Room va Retrofit uchun Fake-obyektlar yaratish

Room uchun Fake-repozitoriya — Android-da fake-ning odatiy namunasi. Ishlab chiqarish UserRepository implementatsiyasi SQLite so‘rovlari bilan Room DAO-dan foydalanadi. Fake versiyasi ma’lumotlarni MutableList yoki HashMap-da saqlaydi va bir xil metodlarni implementatsiya qiladi: getUser(id), saveUser(user), deleteUser(id). Fake qidirish, filtrlash va saralash mantiqini o‘z ichiga oladi — ishlab chiqarish repozitoriyasi kabi, ammo SQLsiz. Bu Room bazasini sozlamasdan ViewModel va UseCase-ni test qilish imkonini beradi.

class FakeUserRepository : UserRepository {

    private val users = mutableListOf<User>()

    override suspend fun getUser(id: String): User? {
        return users.find { it.id == id }
    }

    override suspend fun saveUser(user: User) {
        val index = users.indexOfFirst { it.id == user.id }
        if (index >= 0) users[index] = user
        else users.add(user)
    }

    override suspend fun search(query: String): List<User> {
        return users.filter {
            it.name.contains(query, ignoreCase = true)
        }
    }
}

Retrofit API uchun Fake — MockWebServer (stub, fake emas) o‘rniga in-memory kolleksiyadan ma’lumotlarni qaytaradigan ApiService implementatsiyasini yaratish mumkin. Farq: MockWebServer HTTP ni tutadi va JSON qaytaradi, fake-ApiService esa serializatsiyasiz Kotlin interfeys darajasida ishlaydi. Fake tezroq (JSON parsingsiz) va nosozliklarni tuzatishda soddaroq (bir jarayonda ishlaydi, tiplashtirilgan). HTTP semantikasi (status kodlari, sarlavhalar) muhim bo‘lmagan testlar uchun mos keladi.

Tezkor testlar uchun FakeSharedPreferences

iOS-da in-memory xotira bilan Fake implementatsiyalari

Swift-da Fake — protokollar orqali quriladi. Ishlab chiqarish sinfi real mantiq (CoreData, URLSession) bilan protokolni implementatsiya qiladi. Fake strukturasi bir xil protokolni in-memory xotira va soddalashtirilgan mantiq bilan implementatsiya qiladi. Swift qiymat semantikasiga ega til, shuning uchun fake strukturalari o‘zgarmas va ko‘p oqimli testlarda xavfsizdir. Bu Android analoglari ustidan afzallik beradi: in-memory ma’lumotlarga kirishni sinxronlashtirish shart emas.

protocol UserRepositoryProtocol {
    func getUser(id: String) async -> User?
    func saveUser(user: User) async
}

final class FakeUserRepository: UserRepositoryProtocol {
    private var storage: [String: User] = [:]

    func getUser(id: String) async -> User? {
        return storage[id]
    }

    func saveUser(user: User) async {
        storage[user.id] = user
    }
}

final class UserViewModelTests: XCTestCase {
    func test_save_and_load() async {
        let fake = FakeUserRepository()
        let vm = UserViewModel(repository: fake)
        let user = User(id: "1", name: "Alice")

        await vm.saveUser(user)
        let loaded = await vm.getUser(id: "1")

        XCTAssertEqual(loaded?.name, "Alice")
    }
}

CoreData uchun Fake — iOS loyihalarida description.type = NSInMemoryStoreType ko‘rsatish orqali in-memory NSPersistentContainer yaratish mumkin. Bu to‘liq CoreData steki, ammo xotirada ishlaydi. Bunday fake SQLite faylini yaratmasdan NSFetchRequest, predikatlar va saralashlarni test qilish imkonini beradi. Tezlik: in-memory CoreData testlari disk analogidan 5-10 marta tez bajariladi. Kamchilik: har safar NSManagedObjectModel-ni sozlash kerak.

FakeURLProtocol — iOS-da tarmoq so‘rovlarini tutish uchun URLProtocol kichik sinfi. URLProtocol.registerClass(fakeProtocol) orqali ro‘yxatdan o‘tadi. Ichida URL -> Data in-memory lug‘atini saqlaydi va real so‘rovsiz ma’lumotlarni qaytaradi. Stub-dan farqi: FakeURLProtocol so‘rov tanasini, sarlavhalarni tekshirishi va kirish ma’lumotlariga qarab turli javoblarni qaytarishi mumkin. Bu fake, chunki so‘rov marshrutlash mantiqini o‘z ichiga oladi.

Mobil loyihalarda Fake foydalanish naqshlari

Test Fixture sifatida Fake — fake sinflarini umumiy test moduliga (androidTest/sharedTest yoki TestSupport) chiqaring. Loyihadagi barcha testlar bir xil InMemoryUserRepository-dan foydalanadi. Bu har bir testda mock obyektlarini sozlashning takrorlanishini bartaraf qiladi va bir xil xatti-harakatni kafolatlaydi. Fake mantiqining o‘zgarishi barcha testlarni bir vaqtda yangilaydi. IT Sectr-da biz fake sinflarini sharedTest/java/com/itSectr/fake/ da saqlaymiz va implementation project(:sharedTest) orqali ulaymiz.

Oldindan o‘rnatilgan ma’lumotlar bilan Fake — ko‘pincha testlarga allaqachon ba‘zi yozuvlarga ega repozitoriya kerak bo‘ladi. Yechim: fakeWithData(vararg items) fabrika metodi yoki o‘rnatilgan addDefaultData() metodi. Fabrika fake yaratadi, uni odatiy ma’lumotlar bilan to‘ldiradi va foydalanishga tayyor obyektni qaytaradi. Bu testlarda boilerplate-ni kamaytiradi: mock chaqiruvlarini sozlash o‘rniga test shunchaki FakeUserRepository.withUsers(alice, bob) ni chaqiradi.

Chaqiruvlar soni bilan Fake — ba‘zida nafaqat holatni, balki murojaatlar sonini ham tekshirish kerak. Fake hisoblagichlarni o‘z ichiga olishi mumkin: saveCallCount, getUserCallCount. Test bajarilgandan so‘ng hisoblagichni tekshiradi. Bu toza fake (holatni tekshirish) va mock (o‘zaro ta‘sirni tekshirish) o‘rtasidagi kelishuvdir. Hisoblagichlar argumentlar va chaqiruvlar tartibini tekshirmaydi — faqat sonni. Argumentlarni tekshirish uchun mock-dan foydalaning.

Callback bilan Fake — asinxron stsenariylarni test qilish uchun fake har bir chaqiruvda callback qabul qilishi mumkin: beforeGetUser, afterSaveUser. Bu kechikishlarni, xatolarni simulyatsiya qilish yoki oraliq holatlarni tekshirish imkonini beradi. Bunday yondashuv UI-ning yuklanish holatlarini test qilish uchun foydalidir: fake 100 ms pauza qiladi, test esa ekran yuklagichni ko‘rsatayotganini tekshiradi. Ishlab chiqarish muhitida callback mavjud emas — bu sof test funksionalligi.