Fake — یہ کیا ہے، مقصد اور ٹیسٹنگ میں کیسے استعمال کریں

Fake کیا ہے اور ٹیسٹنگ میں اس کی ضرورت کیوں ہے؟

Fake ایک انٹرفیس کا مکمل لیکن ہلکا نفاذ ہے جو ٹیسٹنگ کے لیے موزوں ہے۔ یہ اصطلاح Gerard Meszaros (2007) نے کتاب “xUnit Test Patterns” میں متعارف کرائی تھی۔ Stub کے برعکس، جو ہارڈ کوڈڈ جوابات لوٹاتا ہے، fake میں قابل عمل کوڈ ہوتا ہے: یہ فہرست ترتیب دے سکتا ہے، شرط کے مطابق فلٹر کر سکتا ہے، ریکارڈ گن سکتا ہے۔ پروڈکشن نفاذ سے واحد فرق یہ ہے کہ fake ان میموری ڈیٹا کے ساتھ کام کرتا ہے اور حقیقی I/O آپریشنز نہیں کرتا۔

بنیادی فائدہ رفتار ہے۔ Fake کے ساتھ ٹیسٹ ملی سیکنڈز میں مکمل ہوتے ہیں کیونکہ ڈسک، نیٹ ورک یا ڈیٹابیس تک رسائی نہیں ہوتی۔ ان میموری HashMap Room یا CoreData سے 100–1000 گنا تیز کام کرتا ہے۔ ایک ہی وقت میں، fake حقیقی کاروباری منطق کی جانچ کرتا ہے: ترتیب دینا، فلٹر کرنا، جمع کرنا — وہ سب کچھ جو stub جانچ نہیں سکتا کیونکہ stub صرف وہی لوٹاتا ہے جو اسے بتایا گیا۔ Fake یقین دلاتا ہے کہ کوڈ ڈیٹا کو صحیح طریقے سے پروسیس کرتا ہے، بجائے اس کے کہ صرف پہلے سے طے شدہ جواب حاصل کرے۔

Fake کب Stub سے بہتر ہے

Fake Stub سے بہتر ہے — اگر ٹیسٹ کے تحت جزو ڈیٹا پر متعدد آپریشنز کرتا ہے (حاصل کرنا، فلٹر کرنا، ترتیب دینا، محفوظ کرنا)، تو stub کو ہر کال کو الگ سے ترتیب دینے کی ضرورت ہوگی۔ Fake منطق خود اپنے اندر رکھتا ہے — ٹیسٹ صرف طریقوں کو کال کرتا ہے اور نتیجہ چیک کرتا ہے۔ IT Sectr میں، ہم یونٹ ٹیسٹوں میں تمام ذخیروں کے لیے fakes استعمال کرتے ہیں: HashMap کے ساتھ ایک fake ذخیرہ Mockito یا MockK ترتیب دیے بغیر 90% منظرناموں کو کور کرتا ہے۔

Fake vs Stub vs Mock: کب کیا انتخاب کریں

انتخاب کا معیار — طے کریں کہ ٹیسٹ کیا تصدیق کرتا ہے: حالت یا تعامل۔ اگر ٹیسٹ حالت (کام کا نتیجہ) تصدیق کرتا ہے اور منطق استعمال کرتا ہے — fake استعمال کریں۔ اگر ٹیسٹ کو صرف منطق کے بغیر ان پٹ ڈیٹا کی ضرورت ہے — stub کافی ہے۔ اگر ٹیسٹ تصدیق کرتا ہے کہ کوئی طریقہ کال کیا گیا — mock استعمال کریں۔ ایک ٹیسٹ میں test doubles کی اقسام ملانا تفہیم کو پیچیدہ بناتا ہے اور نزاکت بڑھاتا ہے۔

اینٹی پیٹرن: Fake جو fake نہیں ہے — ایک عام غلطی جب ڈیولپر کسی شے کو fake کہتا ہے جو حقیقت میں stub یا mock ہے۔ اگر آپ کا InMemoryUserRepository کوئی منطق (فلٹرنگ، ترتیب) نہیں رکھتا — یہ fake نہیں ہے، بلکہ ان میموری اسٹوریج کے ساتھ stub ہے۔ Fake stub سے قابل عمل منطق کی موجودگی کی وجہ سے مختلف ہوتا ہے۔ اگر ایک fake ذخیرہ صرف وہی لوٹاتا ہے جو اس میں ڈالا گیا اور ڈیٹا پروسیس نہیں کرتا — mock یا stub استعمال کریں۔

Test Double انتخاب کے لیے عملی اصول

عملی سفارش — ہر ذخیرے یا سروس کے لیے fake سے شروع کریں۔ اگر fake 50 لائنوں سے زیادہ ہو — اسے متعدد کلاسوں میں تقسیم کریں۔ اگر fake کی بالکل ضرورت نہ ہو (ٹیسٹ صرف مقررہ ڈیٹا کے ساتھ ایک منظرنامے کی تصدیق کرتا ہے) — stub استعمال کریں۔ اگر ٹیسٹ تصدیق کرتا ہے کہ کوئی طریقہ مخصوص پیرامیٹرز کے ساتھ کال کیا گیا — mock استعمال کریں۔ پہلے سے انتخاب کو بہتر نہ بنائیں: ایک fake لکھیں، اور اگر یہ ضرورت سے زیادہ ہو، تو کسی مخصوص ٹیسٹ میں اسے stub سے بدل دیں۔

Android پر Room اور Retrofit کے لیے Fake اشیاء بنانا

Room کے لیے Fake ذخیرہ — Android پر fake کی ایک عام مثال۔ UserRepository کا پروڈکشن نفاذ SQLite سوالات کے ساتھ Room DAO استعمال کرتا ہے۔ Fake ورژن MutableList یا HashMap میں ڈیٹا محفوظ کرتا ہے اور وہی طریقے نافذ کرتا ہے: getUser(id)، saveUser(user)، deleteUser(id)۔ Fake میں تلاش، فلٹرنگ اور ترتیب کی منطق ہوتی ہے — پروڈکشن ذخیرے کی طرح، لیکن SQL کے بغیر۔ یہ Room ڈیٹابیس ترتیب دیے بغیر ViewModel اور UseCase کی جانچ کرنے کی اجازت دیتا ہے۔

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 کے لیے Fake — MockWebServer (جو stub ہے، fake نہیں) کے بجائے، آپ ایک ApiService نفاذ بنا سکتے ہیں جو ان میموری کلیکشن سے ڈیٹا لوٹاتا ہے۔ فرق: MockWebServer HTTP کو روکتا ہے اور JSON لوٹاتا ہے، جبکہ fake ApiService سیریلائزیشن کے بغیر Kotlin انٹرفیس سطح پر کام کرتا ہے۔ Fake تیز تر ہے (کوئی JSON پارسنگ نہیں) اور ڈیبگ کرنا آسان ہے (اسی عمل میں چلتا ہے، ٹائپ کیا ہوا)۔ ان ٹیسٹوں کے لیے موزوں جہاں HTTP سیمنٹکس (اسٹیٹس کوڈ، ہیڈر) اہم نہیں ہیں۔

تیز ٹیسٹوں کے لیے FakeSharedPreferences

iOS پر ان میموری اسٹوریج کے ساتھ Fake نفاذ

Swift میں Fake — پروٹوکول کے ذریعے بنایا جاتا ہے۔ پروڈکشن کلاس حقیقی منطق (CoreData، URLSession) کے ساتھ پروٹوکول نافذ کرتی ہے۔ Fake ساخت ان میموری اسٹوریج اور آسان منطق کے ساتھ وہی پروٹوکول نافذ کرتی ہے۔ Swift قدر سیمنٹکس والی زبان ہے، لہذا fake ساختیں ناقابل تبدیل اور ملٹی تھریڈڈ ٹیسٹوں میں محفوظ ہیں۔ یہ Android کے مشابہ پر فائدہ دیتا ہے: ان میموری ڈیٹا تک رسائی کو ہم آہنگ کرنے کی ضرورت نہیں ہے۔

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 کے لیے Fake — iOS پروجیکٹس میں، آپ description.type = NSInMemoryStoreType سیٹ کر کے ان میموری NSPersistentContainer بنا سکتے ہیں۔ یہ ایک مکمل CoreData اسٹیک ہے، لیکن میموری میں چل رہا ہے۔ ایسا fake SQLite فائل بنائے بغیر NSFetchRequest، پیش گوئیاں اور ترتیبات جانچنے کی اجازت دیتا ہے۔ رفتار: ان میموری CoreData پر ٹیسٹ ڈسک پر مبنی مشابہ سے 5–10 گنا تیزی سے چلتے ہیں۔ کمزوری: ہر بار NSManagedObjectModel ترتیب دینے کی ضرورت ہے۔

FakeURLProtocol — iOS پر نیٹ ورک درخواستوں کو روکنے کے لیے URLProtocol کا ایک ذیلی طبقہ۔ یہ URLProtocol.registerClass(fakeProtocol) کے ذریعے رجسٹر ہوتا ہے۔ اندرونی طور پر اس میں ان میموری URL -> Data ڈکشنری ہوتی ہے اور حقیقی درخواست کے بغیر ڈیٹا لوٹاتا ہے۔ Stub سے فرق: FakeURLProtocol درخواست کے باڈی، ہیڈر چیک کر سکتا ہے اور ان پٹ ڈیٹا کے لحاظ سے مختلف جوابات لوٹا سکتا ہے۔ یہ fake ہے کیونکہ اس میں درخواست روٹنگ منطق ہے۔

موبائل پروجیکٹس میں Fake استعمال کے نمونے

Test Fixture کے طور پر Fake — fake کلاسوں کو مشترکہ ٹیسٹ ماڈیول (androidTest/sharedTest یا TestSupport) میں رکھیں۔ پروجیکٹ کے تمام ٹیسٹ ایک ہی InMemoryUserRepository استعمال کرتے ہیں۔ یہ ہر ٹیسٹ میں mock شے کی ترتیب کے تکرار کو ختم کرتا ہے اور یکساں رویے کی ضمانت دیتا ہے۔ Fake کی منطق تبدیل کرنا تمام ٹیسٹوں کو ایک ساتھ اپ ڈیٹ کرتا ہے۔ IT Sectr میں، ہم fake کلاسوں کو sharedTest/java/com/itSectr/fake/ میں محفوظ کرتے ہیں اور انہیں implementation project(:sharedTest) کے ذریعے شامل کرتے ہیں۔

پہلے سے طے شدہ ڈیٹا کے ساتھ Fake — اکثر ٹیسٹوں کو ایک ایسے ذخیرے کی ضرورت ہوتی ہے جس میں پہلے سے کچھ ریکارڈ ہوں۔ حل: ایک فیکٹری طریقہ fakeWithData(vararg items) یا ایک بلٹ ان addDefaultData() طریقہ۔ فیکٹری ایک fake بناتی ہے، اسے عام ڈیٹا سے بھرتی ہے اور استعمال کے لیے تیار شے لوٹاتی ہے۔ یہ ٹیسٹوں میں بائلرپلیٹ کو کم کرتا ہے: mock کالز ترتیب دینے کے بجائے، ٹیسٹ صرف FakeUserRepository.withUsers(alice, bob) کال کرتا ہے۔

کال گنتی کے ساتھ Fake — کبھی کبھی صرف حالت نہیں بلکہ کالوں کی تعداد بھی تصدیق کرنی ہوتی ہے۔ Fake میں کاؤنٹر ہو سکتے ہیں: saveCallCount، getUserCallCount۔ ٹیسٹ عملدرآمد کے بعد کاؤنٹر چیک کرتا ہے۔ یہ خالص fake (حالت کی تصدیق) اور mock (تعامل کی تصدیق) کے درمیان ایک سمجھوتہ ہے۔ کاؤنٹر آرگیومنٹس یا کال ترتیب نہیں چیک کرتے — صرف تعداد۔ آرگیومنٹس کی تصدیق کے لیے، mock استعمال کریں۔

Callback کے ساتھ Fake — غیر متزامن منظرناموں کی جانچ کے لیے، fake ہر کال پر ایک callback قبول کر سکتا ہے: beforeGetUser، afterSaveUser۔ یہ تاخیر، غلطیاں نقل کرنے یا درمیانی حالتیں چیک کرنے کی اجازت دیتا ہے۔ یہ طریقہ UI لوڈنگ حالتوں کی جانچ کے لیے مفید ہے: fake 100 ms کے لیے رکتا ہے، اور ٹیسٹ تصدیق کرتا ہے کہ اسکرین لوڈر دکھاتی ہے۔ Callback پروڈکشن میں موجود نہیں ہے — یہ خالصتاً ٹیسٹ فعالیت ہے۔