Stub: یہ کیا ہے، اقسام اور ٹیسٹنگ میں استعمال

Stub کیا ہے اور یہ دوسرے test doubles سے کیسے مختلف ہے؟

Stub — ایک اسٹب آبجیکٹ ہے جو ٹیسٹ میں حقیقی انحصار کو تبدیل کرتا ہے اور مخصوص کالز پر پہلے سے طے شدہ قدریں لوٹاتا ہے۔ یہ اصطلاح Gerard Meszaros (2007) کی کتاب «xUnit Test Patterns» میں درجہ بندی میں متعارف کرائی گئی تھی۔ Stub کا تعلق test doubles کے زمرے سے ہے — وہ آبجیکٹ جو ٹیسٹنگ کے دوران حقیقی اجزاء کو تبدیل کرتے ہیں۔ اسٹب کا بنیادی مقصد ٹیسٹ کیے جانے والے بلاک کو متوقع ڈیٹا فراہم کرنا ہے، بیرونی نظاموں کی غیر یقینییت کو ختم کرنا۔

کام کرنے کا اصول — ٹیسٹ اسٹب کو عملدرآمد سے پہلے ترتیب دیتا ہے: «جب getUsers() میتھڈ کال کیا جائے، تو صارفین کی یہ فہرست لوٹا دو»۔ Stub میں کاروباری منطق نہیں ہوتی، یہ کالز کی ترتیب کی جانچ نہیں کرتا اور رسائی کی تاریخ ریکارڈ نہیں کرتا۔ یہ صرف حقیقی جزو کی جگہ پر کھڑا ہوتا ہے اور وہی لوٹاتا ہے جو اسے کہا گیا۔ Android ٹیسٹنگ کے تناظر میں اس کا مطلب ہے: OkHttp کلائنٹ سرور پر حقیقی درخواست نہیں بھیجتا، بلکہ MockWebServer سے جواب حاصل کرتا ہے جو بطور اسٹب ترتیب دیا گیا ہے۔

• Stub — ڈیٹا لوٹاتا ہے، کالز کی جانچ نہیں کرتا
• Mock — ڈیٹا لوٹاتا ہے اور رویے کی جانچ کرتا ہے (verify)
• Fake — حقیقی منطق کے ساتھ آسان نفاذ
• Spy — حقیقی آبجیکٹ کو لپیٹتا ہے، کالز ریکارڈ کرتا ہے
• Dummy — منتقل کیا جاتا ہے لیکن استعمال نہیں ہوتا (null، خالی آبجیکٹ)

کب استعمال کریں — اسٹبس UI-لیئر (ViewModel، Presenter) اور کاروباری منطق (UseCase، Interactor) کی جانچ کے لیے بہترین ہیں، جہاں مخصوص ڈیٹا پر ردعمل جانچنے کی ضرورت ہو: فہرست خالی ہے، سرور نے 500 ایرر لوٹایا، ٹوکن کی میعاد ختم ہوئی۔ کوئی بھی کیس جہاں ٹیسٹ کو مخصوص انپٹ حالت کی ضرورت ہو — یہ stub کا کام ہے۔ ہر ٹیسٹ منظرنامے کے لیے اسٹب کی اپنی ترتیب بنائی جاتی ہے، جو ٹیسٹ کو پڑھنے کے قابل اور متوقع بناتی ہے۔

Meszaros کے مطابق test doubles کی درجہ بندی

Gerard Meszaros (2007) نے اپنی کتاب «xUnit Test Patterns» میں test doubles کی پانچ اقسام بیان کی ہیں: dummy, stub, spy, mock, fake۔ ہر قسم اپنا مسئلہ حل کرتی ہے۔ Dummy — منتقل کیا جاتا ہے لیکن استعمال نہیں ہوتا۔ Stub — ڈیٹا لوٹاتا ہے۔ Spy — کالز ریکارڈ کرتا ہے۔ Mock — رویے کی جانچ کرتا ہے۔ Fake — آسان منطق پر مشتمل ہوتا ہے۔ اس درجہ بندی کو سمجھنا ڈویلپر کو ہر ٹیسٹ منظرنامے کے لیے صحیح آلہ منتخب کرنے میں مدد دیتا ہے۔

موبائل ایپلیکیشنز کی ٹیسٹنگ میں اسٹبس کہاں استعمال ہوتے ہیں

نیٹ ورک درخواستوں کے لیے اسٹبس

نیٹ ورک درخواستیں — اسٹبس کے استعمال کا سب سے عام منظرنامہ۔ ایپلیکیشن API کو HTTP کالز کرتی ہے، اور ٹیسٹ میں مختلف جوابات پر ردعمل جانچنے کی ضرورت ہوتی ہے: کامیاب JSON، 401 ایرر (غیر مصدقہ)، ٹائم آؤٹ، خالی صف۔ Android پر MockWebServer (OkHttp) اور iOS پر URLProtocol اسٹبس کے طور پر کام کرتے ہیں، سرور سے حقیقی کنیکشن کے بغیر پہلے سے طے شدہ HTTP جوابات لوٹاتے ہیں۔ یہ ٹیسٹ کو سیکنڈوں سے ملی سیکنڈز تک تیز کرتا ہے۔

ڈیٹا بیس — Android میں Room اور iOS میں CoreData کے in-memory ورژن موجود ہیں، لیکن ان کی ترتیب میں وقت لگتا ہے۔ اسٹب بطور ریپوزٹری ڈیٹا بیس کو چھوئے بغیر پہلے سے تیار شدہ Entity فہرستیں لوٹاتا ہے۔ یہ ViewModel کی جانچ کے لیے خاص طور پر مؤثر ہے، جہاں ترتیب، فلٹرنگ یا ڈیٹا کی تبدیلی جانچنے کی ضرورت ہو۔ ڈیٹا کے حجم سے قطع نظر، ٹیسٹ ملی سیکنڈز میں مکمل ہوتا ہے۔

سسٹم سروسز — LocationManager، SensorManager، SharedPreferences کو حقیقی ڈیوائس یا ایمولیٹر کی ضرورت ہوتی ہے۔ LocationProvider کے لیے اسٹب مخصوص کوآرڈینیٹ لوٹاتا ہے، SensorManager کے لیے — ایکسلرومیٹر کی طے شدہ قدریں۔ iOS پر مشابہ — CLLocationManager ڈیلیگیٹ کے ٹیسٹ نفاذ کے ساتھ۔ اسٹبس کے بغیر ایسے ٹیسٹوں کے لیے مخصوص شرائط والے فزیکل ڈیوائس کی ضرورت ہوتی ہے۔

فائل سسٹم اور کیش — تصاویر لوڈ کرنا، جوابات کیش کرنا، کنفیگریشن فائلوں کے ساتھ کام — یہ تمام کارروائیاں ڈسک کی حالت پر منحصر ہیں۔ FileManager یا ImageCache کے لیے اسٹب حقیقی فائلیں پڑھے بغیر کامیابی/ناکامی لوٹاتا ہے۔ یہ مختلف ڈویلپر مشینوں پر پاتھ یا رسائی کے حقوق کے فرق کی وجہ سے ٹیسٹوں کے غلط فیل ہونے کو ختم کرتا ہے۔

Stub vs Mock vs Fake: اہم فرق

ذمہ داری کی تقسیم — تینوں اقسام کے test doubles مختلف مسائل حل کرتے ہیں۔ Stub: «مجھے ڈیٹا دو»۔ Mock: «تصدیق کرو کہ مجھے کال کیا گیا»۔ Fake: «میں اصلی کی طرح کام کرتا ہوں، صرف آسان»۔ یہ فرق ٹیسٹ کی پڑھنے کی اہلیت کے لیے انتہائی اہم ہے: اگر ٹیسٹ mock استعمال کرتا ہے جہاں stub کی ضرورت ہے، تو یہ verify کالز سے بھر جاتا ہے جن کا جانچے جانے والے منظرنامے سے کوئی تعلق نہیں۔

عملی اصول — اگر ٹیسٹ جانچتا ہے کہ ٹیسٹ کیے جانے والے جزو کو کون سا ڈیٹا ملا — stub استعمال کریں۔ اگر ٹیسٹ جانچتا ہے کہ جزو نے انحصار کے میتھڈ کو صحیح آرگیومنٹس کے ساتھ کال کیا — mock استعمال کریں۔ اگر آپ صرف DB کو ہیش ٹیبل سے تبدیل کرنا چاہتے ہیں — یہ fake ہے۔ ایک ٹیسٹ میں اقسام کو ملانا اسے نازک بنا دیتا ہے: نفاذ تبدیل کرنے پر stub اور verify منطق دونوں کو دوبارہ لکھنا پڑے گا۔

اینٹی پیٹرن: verify کے ساتھ Stub

verify کے ساتھ Stub — ایک عام غلطی جہاں ڈویلپر stub ترتیب دیتا ہے اور پھر verify(stub).method() شامل کرتا ہے۔ Stub کو تعریف کے مطابق تصدیق نہیں کرنی چاہیے — تصدیق کے لیے mock ہے۔ اگر آپ کو جانچنا ہے کہ میتھڈ کو مخصوص آرگیومنٹس کے ساتھ کال کیا گیا، تو Mockito.stub() کی بجائے Mockito.mock() استعمال کریں۔ یہ علیحدگی دوسرے ڈویلپرز کے لیے ٹیسٹ کے ارادے کو واضح رکھتی ہے۔

MockWebServer اور MockK کے ساتھ Android پر اسٹبس کا نفاذ

MockWebServer — OkHttp لائبریری Android اور JVM پر HTTP اسٹبس بنانے کے لیے۔ یہ مخصوص پورٹ پر لوکل HTTP سرور شروع کرتا ہے، جو OkHttp کلائنٹ کی درخواستوں کو روکتا ہے اور پہلے سے طے شدہ جوابات لوٹاتا ہے۔ ترتیب تین لائنوں میں مکمل ہوتی ہے: سرور بنائیں، جواب enqueue کریں، شروع کریں۔ ٹیسٹ صفحہ بندی یا ریٹری کے منظرناموں کے لیے لگاتار کئی جوابات enqueue کر سکتا ہے۔

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 کے لیے Mockito کا متبادل جس میں کوروٹینز، extension-فنکشنز اور sealed-کلاسز کے لیے first-class سپورٹ ہے۔ MockK میں اسٹبس coEvery (suspend-فنکشنز کے لیے) اور every (عام کے لیے) کے ذریعے بنائے جاتے ہیں۔ MockWebServer کے برعکس، MockK انفرادی میتھڈ-انحصاروں کو اسٹب کرتا ہے، نہ کہ پورے HTTP-لیئر کو۔ یہ UseCase یا Interactor کے unit-ٹیسٹوں کے لیے آسان ہے، جہاں انحصار ریپوزٹری کی تجریدیں ہیں۔

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 — انٹیگریشن ٹیسٹوں کے لیے MockWebServer استعمال کریں (حقیقی HTTP کو روکتا ہے)، unit-ٹیسٹوں کے لیے — MockK (انٹرفیس کو اسٹب کرتا ہے)۔ جسے آپ ٹیسٹ نہیں کر رہے اسے اسٹب نہ کریں: اگر ٹیسٹ Repository کی جانچ کر رہا ہے، تو اس کے اندر OkHttp-کلائنٹ کو اسٹب نہ کریں — HTTP کی سطح پر حقیقی MockWebServer استعمال کریں۔ یہ اصول ٹیسٹ کو متعلقہ رکھتا ہے اور ریفیکٹرنگ کے دوران نزاکت کو کم کرتا ہے۔

OCMock اور پروٹوکولز کے ساتھ iOS پر اسٹبس کا نفاذ

Swift-پروٹوکولز بطور اسٹب — iOS-native طریقہ کار میں اسٹب انحصار کے پروٹوکول پر پورا اترنے والی ٹیسٹ ساخت کے ذریعے لاگو کیا جاتا ہے۔ حقیقی NetworkService کی جگہ ٹیسٹ کو StubNetworkService ملتا ہے، جو طے شدہ ڈیٹا لوٹاتا ہے۔ Swift ایک جامد ٹائپنگ والی زبان ہے، اس لیے اسٹب کو حقیقی سروس کے same پروٹوکول پر پورا اترنا چاہیے۔ مرتب کنندہ اس بات کی ضمانت دیتا ہے کہ اسٹب تمام مطلوبہ میتھڈز کو لاگو کرتا ہے۔

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 کے لیے OCMock — legacy iOS پراجیکٹس میں اسٹبس اور موکس بنانے کی لائبریری۔ OCMock آرگیومنٹس اور ریٹرن ویلیوز کے ساتھ stub-میتھڈز کو سپورٹ کرتا ہے۔ Swift پر جدید پراجیکٹس protocol-based طریقہ کار کو دستی اسٹبس کے ساتھ ترجیح دیتے ہیں — یہ ہر میتھڈ پر کنٹرول دیتا ہے اور بیرونی انحصار کی ضرورت نہیں ہوتی۔ OCMock ان پراجیکٹس کے لیے ایک آپشن ہے جہاں تمام انحصاروں کا پروٹوکولائزیشن اقتصادی طور پر مناسب نہیں ہے۔

HTTP اسٹبس کے لیے URLProtocol — iOS کا سسٹم میکانزم URLProtocol کے ذیلی طبقے کے ذریعے نیٹ ورک درخواستوں کو روکنے کے لیے۔ ٹیسٹ ایک کسٹم URLProtocol رجسٹر کرتا ہے، جو URLSession کو روکتا ہے اور اسٹب جوابات لوٹاتا ہے۔ دستی اسٹبس کے مقابلے میں فائدہ: ایپلیکیشن کی آرکیٹیکچر تبدیل کرنے کی ضرورت نہیں — URLSession حقیقی رہتا ہے، لیکن ڈیٹا پروٹوکول کی سطح پر تبدیل کیا جاتا ہے۔ نقصان: واضح اسٹب سروس کے مقابلے میں ڈیبگ کرنا مشکل ہے۔