Fake — ما هو، الغرض منه وكيفية استخدامه في الاختبار

ما هو Fake ولماذا هو مطلوب في الاختبار؟

Fake هو تطبيق كامل لكن خفيف لواجهة، مناسب للاختبار. تم تقديم المصطلح بواسطة Gerard Meszaros (2007) في كتاب «xUnit Test Patterns.» على عكس stub، الذي يعيد إجابات محددة مسبقا، يحتوي fake على كود قابل للتنفيذ: يمكنه فرز قائمة، تصفية حسب شرط، عد السجلات. الفرق الوحيد عن تطبيق الإنتاج هو أن fake يعمل مع بيانات في الذاكرة ولا يقوم بعمليات إدخال/إخراج حقيقية.

الميزة الرئيسية هي السرعة. يتم تنفيذ الاختبارات باستخدام fake خلال أجزاء من الثانية لأنه لا يوجد وصول إلى القرص أو الشبكة أو قاعدة البيانات. يعمل HashMap في الذاكرة أسرع 100–1000 مرة من Room أو CoreData. في نفس الوقت، يختبر fake منطق الأعمال الحقيقي: الفرز، التصفية، التجميع — كل ما لا يستطيع stub اختباره لأنه يعيد فقط ما قيل له. يمنح fake الثقة في أن الكود يعالج البيانات بشكل صحيح، بدلا من مجرد تلقي إجابة محددة مسبقا.

متى يكون Fake أفضل من Stub

Fake أفضل من Stub — إذا كان المكون قيد الاختبار يقوم بعمليات متعددة على البيانات (استرجاع، تصفية، فرز، حفظ)، فإن stub سيتطلب تكوين كل استدعاء على حدة. يحتوي fake على المنطق داخله — الاختبار ببساطة يستدعي الطرق ويتحقق من النتيجة. في IT Sectr، نستخدم fakes لجميع المستودعات في اختبارات الوحدة: مستودع fake مع HashMap يغطي 90% من السيناريوهات دون إعداد Mockito أو MockK.

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 في اختبار محدد.

إنشاء كائنات Fake على Android لـ Room و Retrofit

مستودع fake لـ Room — مثال نموذجي لـ fake على Android. يستخدم تطبيق الإنتاج لـ UserRepository واجهة Room DAO مع استعلامات SQLite. النسخة fake تخزن البيانات في MutableList أو HashMap وتنفذ نفس الطرق: getUser(id)، saveUser(user)، deleteUser(id). يحتوي fake على منطق البحث والتصفية والفرز — نفس مستودع الإنتاج، لكن دون SQL. هذا يسمح باختبار ViewModel و UseCase دون إعداد قاعدة بيانات Room.

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)
        }
    }
}

Fake لواجهة Retrofit API — بدلا من MockWebServer (وهو stub، ليس fake)، يمكنك إنشاء تطبيق ApiService يعيد البيانات من مجموعة في الذاكرة. الفرق: MockWebServer يعترض HTTP ويعيد JSON، بينما يعمل fake ApiService على مستوى واجهة Kotlin دون تسلسل. fake أسرع (لا يوجد تحليل JSON) وأسهل في التصحيح (يعمل في نفس العملية، مقيد بالنوع). مناسب للاختبارات حيث دلالات HTTP (رموز الحالة، الرؤوس) ليست مهمة.

FakeSharedPreferences للاختبارات السريعة

تطبيقات Fake على iOS مع تخزين في الذاكرة

Fake في Swift — يُبنى من خلال البروتوكولات. تنفذ فئة الإنتاج البروتوكول مع منطق حقيقي (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")
    }
}

Fake لـ CoreData — في مشاريع iOS، يمكنك إنشاء NSPersistentContainer في الذاكرة عن طريق تعيين description.type = NSInMemoryStoreType. هذا مكدس CoreData كامل، لكن يعمل في الذاكرة. يسمح هذا fake باختبار NSFetchRequest و المسندات والفرز دون إنشاء ملف SQLite. السرعة: اختبارات CoreData في الذاكرة تعمل أسرع 5–10 مرات من النظير على القرص. العيب: تحتاج إلى إعداد NSManagedObjectModel في كل مرة.

FakeURLProtocol — فئة فرعية من URLProtocol لاعتراض طلبات الشبكة على iOS. يتم تسجيلها عبر URLProtocol.registerClass(fakeProtocol). داخليا تحتوي على قاموس URL -> Data في الذاكرة وتعيد البيانات دون طلب حقيقي. الفرق عن stub: يمكن لـ FakeURLProtocol التحقق من جسم الطلب والرؤوس وإرجاع ردود مختلفة حسب بيانات الإدخال. هذا هو fake لأنه يحتوي على منطق توجيه الطلبات.

أنماط استخدام Fake في مشاريع الجوال

Fake كـ Test Fixture — ضع فئات 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.

Fake مع Callback — لاختبار السيناريوهات غير المتزامنة، يمكن أن يقبل fake رد اتصال في كل استدعاء: beforeGetUser، afterSaveUser. هذا يسمح بمحاكاة التأخيرات والأخطاء أو التحقق من الحالات الوسيطة. هذا النهج مفيد لاختبار حالات التحميل في واجهة المستخدم: fake يتوقف لمدة 100 مللي ثانية، والاختبار يتحقق من أن الشاشة تظهر مؤشر التحميل. رد الاتصال غير موجود في الإنتاج — هذه وظيفة اختبارية بحتة.