Mockito — یہ کیا ہے، کلیدی تصورات اور کام کرنے کا اصول

Mockito کیا ہے؟

Mockito Java، Kotlin اور دیگر JVM زبانوں میں یونٹ ٹیسٹوں کے لیے mock آبجیکٹ (stubs) بنانے والی ایک اوپن سورس لائبریری ہے۔ JUnit کے برعکس، جو ٹیسٹ پر عملدرآمد کے لیے ذمہ دار ہے، Mockito علیحدگی کے مسئلے کو حل کرتا ہے — یہ ٹیسٹ کیے جانے والے کلاس کے حقیقی انحصار کو پیش قیاسی آبجیکٹس سے بدل دیتا ہے۔

mock کے بغیر، کسی ایسے میتھڈ کو ٹیسٹ کرنا جو ڈیٹابیس یا بیرونی API تک رسائی حاصل کرتا ہے، حقیقی ماحول قائم کرنے کی ضرورت ہوتی ہے — ڈیٹابیس تعینات کرنا، سرور شروع کرنا۔ Mockito ان انحصاروں کو مقررہ رویے والے آبجیکٹس سے بدل دیتا ہے: repository.findById(1) میتھڈ ڈیٹابیس تک رسائی کیے بغیر ہمیشہ ایک مخصوص User آبجیکٹ واپس کرتا ہے۔

Mockito کا فن تعمیر Proxy پیٹرن (انٹرفیسز اور کلاسز کے لیے) پر مبنی ہے۔ لائبریری مخصوص قسم کے لیے ایک ذیلی کلاس یا پراکسی تیار کرتی ہے اور تمام میتھڈ کالز کو روکتی ہے، ڈیفالٹ ویلیوز یا when().thenReturn() کے ذریعے سیٹ کردہ ویلیوز واپس کرتی ہے۔

Mockito کیسے کام کرتا ہے

Mockito کے کام کرنے کا اصول تین بنیادی کارروائیوں پر مبنی ہے: mock بنانا، رویے کو ترتیب دینا (stubbing) اور کالز کی تصدیق کرنا (verification)۔ ہر کارروائی Maven Central کے اعدادوشمار کے مطابق Java ایکو سسٹم میں سب سے زیادہ ڈاؤن لوڈ کردہ کلاس org.mockito.Mockito سے جامد میتھڈز استعمال کرتی ہے۔ تمام mock میتھڈ کالز میموری میں ریکارڈ کی جاتی ہیں، جو بعد میں verify کے ذریعے تصدیق کی اجازت دیتی ہیں۔

Mockito کے ساتھ ٹیسٹ کے تین مراحل

Mockito کے ساتھ ایک عام ٹیسٹ تین مراحل پر مشتمل ہوتا ہے: Arrange — when().thenReturn() کے ذریعے mocks بنانا اور stubs ترتیب دینا، Act — ٹیسٹ کیے جانے والے میتھڈ کو کال کرنا، Assert — assertEquals اور verify(mock) کے ذریعے نتیجہ جانچنا۔ اس طریقہ کار کو AAA (Arrange-Act-Assert) کہا جاتا ہے۔

ریپوزٹری mock کے ساتھ بنیادی مثال

ایک سادہ ٹیسٹ دیکھیں جہاں Mockito صارف ریپوزٹری کو بدل دیتا ہے۔ when().thenReturn() میتھڈ mock کو اس طرح ترتیب دیتا ہے کہ findById کال پہلے سے تیار کردہ User آبجیکٹ واپس کرے۔

// ریپوزٹری mock بنانا
UserRepository mockRepo = mock(UserRepository.class);

// رویے کو ترتیب دینا: findById(1) ایک صارف واپس کرتا ہے
when(mockRepo.findById(1)).thenReturn(new User("Alice"));

// تصدیق کرنا کہ میتھڈ واقعی کال کی گئی تھی
User result = mockRepo.findById(1);
assertEquals("Alice", result.getName());
verify(mockRepo).findById(1);

mock آبجیکٹ بنانا

Mockito mocks بنانے کے دو طریقے فراہم کرتا ہے: جامد میتھڈ mock(Class) اور MockitoAnnotations.openMocks() کے ذریعے ابتدا کے ساتھ @Mock اینوٹیشن۔ پہلا طریقہ ایک یا دو mocks کے لیے کمپیکٹ ہے، دوسرا اس وقت آسان ہے جب بہت سے انحصار ہوں — اینوٹیشنز boilerplate کوڈ کو کم کرتی ہیں۔

جامد mock() میتھڈ کے ذریعے

mock() میتھڈ ایک کلاس لیتا ہے اور ایک stub آبجیکٹ واپس کرتا ہے جسے when().thenReturn() کے ذریعے ترتیب دیا جا سکتا ہے۔ تمام غیر ترتیب شدہ میتھڈز ڈیفالٹ ویلیوز واپس کرتے ہیں: نمبروں کے لیے 0، boolean کے لیے false، آبجیکٹس کے لیے null۔

ApiClient apiClient = mock(ApiClient.class);
Database database = mock(Database.class);

JUnit 5 کے ساتھ @Mock اینوٹیشن کے ذریعے

@Mock اینوٹیشن @ExtendWith(MockitoExtension.class) کے ساتھ مل کر ٹیسٹ کلاس کے تمام فیلڈز کے لیے خود بخود mocks بناتا ہے۔ MockitoExtension ہر ٹیسٹ سے پہلے ابتدا کے لیے ذمہ دار ہے۔

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void getUserShouldReturnUserFromRepo() {
        when(userRepository.findById(1)).thenReturn(new User("Alice"));
        User result = userService.getUser(1);
        assertEquals("Alice", result.getName());
    }
}

Stubbing: mock کے رویے کو ترتیب دینا

Stubbing اس بات کی تعریف کرنے کا عمل ہے کہ جب کسی مخصوص آرگیومینٹس کے ساتھ کال کیا جائے تو mock میتھڈ کو کیا واپس کرنا چاہیے۔ بنیادی نحو: when(mock.method(args)).thenReturn(value)۔ مختلف منظرناموں کے لیے، Mockito کئی then-میتھڈ variants پیش کرتا ہے۔

thenAnswer کے ذریعے متحرک جواب

جب واپسی کی قیمت کال آرگیومینٹس پر منحصر ہوتی ہے، تو lambda کے ساتھ thenAnswer استعمال کیا جاتا ہے۔ یہ حقیقی ڈیٹا کے ساتھ کام کی نقل کرنے کے لیے مفید ہے — مثال کے طور پر، موصولہ آبجیکٹ کی بنیاد پر ID تیار کرنا۔

when(repository.save(any())).thenAnswer(invocation -> {
    User user = invocation.getArgument(0);
    user.setId(42);
    return user;
});

Verify: mock کے ساتھ تعاملات کی جانچ

Verify Mockito کی ایک منفرد خصوصیت ہے جو پرانی mock آبجیکٹ لائبریریاں (EasyMock، jMock) فراہم نہیں کرتی ہیں۔

Verify ٹیسٹوں کو زیادہ قابل اعتماد بناتا ہے کیونکہ یہ نہ صرف واپسی کی قیمت بلکہ ضمنی اثرات — ان میتھڈز کی کالز جو نتیجہ واپس نہیں کرتی ہیں (void میتھڈز) — بھی جانچتا ہے۔ verify(mock).methodName(args) میتھڈ جانچتا ہے کہ آیا ایک مخصوص mock میتھڈ کو مخصوص آرگیومینٹس کے ساتھ کال کیا گیا تھا۔ یہ نہ صرف نتیجہ بلکہ عمل — انحصار تک رسائی کی حقیقت — کو بھی جانچنے کی اجازت دیتا ہے۔

کالوں کی تعداد کی جانچ

ڈیفالٹ طور پر، verify جانچتا ہے کہ میتھڈ کو بالکل ایک بار کال کیا گیا تھا۔ اگر مختلف تعداد کی ضرورت ہو تو Mockito کلاس سے times(n)، atLeast(n)، never() اور دیگر موڈیفائر استعمال کیے جاتے ہیں۔

// کالوں کی تعداد کی جانچ
verify(repository, times(3)).save(any());
verify(repository, never()).delete(any());
verify(repository, atLeastOnce()).findById(1);

// کالوں کی ترتیب کی جانچ
InOrder inOrder = inOrder(repository);
inOrder.verify(repository).save(any());
inOrder.verify(repository).flush();

آرگیومینٹس کی گرفت کے لیے ArgumentCaptor

جب یہ جانچنا ضروری ہو کہ میتھڈ کو کس عین آبجیکٹ کے ساتھ کال کیا گیا تھا، تو ArgumentCaptor استعمال کیا جاتا ہے۔ یہ کال کے دوران آرگیومینٹ ویلیو کو گرفت میں لیتا ہے اور اس کے فیلڈز کو انفرادی طور پر جانچنے کی اجازت دیتا ہے۔ ArgumentCaptor خاص طور پر اس وقت مفید ہے جب ٹیسٹ کیا جانے والا کوڈ اندرونی طور پر ایک آبجیکٹ بناتا ہے اور اسے انحصار میں منتقل کرتا ہے — آپ اس آبجیکٹ کو دوسری صورت میں جانچ نہیں سکتے۔

ArgumentCaptor<User> captor = ArgumentCaptor.forClass(User.class);
verify(repository).save(captor.capture());
assertEquals("Alice", captor.getValue().getName());

@Mock اور @InjectMocks اینوٹیشنز

@Mock اور @InjectMocks دو اہم Mockito اینوٹیشنز ہیں جو boilerplate کوڈ کو نمایاں طور پر کم کرتی ہیں۔ @Mock ایک فیلڈ کے لیے mock بناتا ہے، اور @InjectMocks ٹیسٹ کلاس سے تمام mocks کو کنسٹرکٹر، سیٹر یا فیلڈ کے ذریعے ٹیسٹ کیے جانے والے آبجیکٹ میں انجیکٹ کرتا ہے۔

@InjectMocks میکانزم درج ذیل ترتیب میں انحصار انجیکٹ کرنے کی کوشش کرتا ہے: سب سے زیادہ آرگیومینٹس والا کنسٹرکٹر، قسم کے مطابق سیٹر، پرائیویٹ فیلڈ۔ اگر ان میں سے کوئی بھی طریقہ کام نہیں کرتا ہے، تو آبجیکٹ null انحصار کے ساتھ رہتا ہے، اور ٹیسٹ NullPointerException کے ساتھ ناکام ہو جائے گا۔

@InjectMocks استعمال کرنے کے قواعد

یہ سمجھنا ضروری ہے: @InjectMocks فیلڈ کی قسموں کا تجزیہ نہیں کرتا — یہ قسم کے مطابق کسی بھی ہم آہنگ mock کو بدل دیتا ہے۔ اگر ایک کلاس میں ایک ہی قسم کے دو فیلڈز ہیں، تو Mockito غلط mock انجیکٹ کر سکتا ہے۔ ایسی صورتوں میں، mock پیرامیٹرز کے ساتھ واضح کنسٹرکٹر استعمال کرنے کی سفارش کی جاتی ہے۔

Android پروجیکٹس میں Mockito

Android ڈیولپمنٹ میں، Mockito JUnit کے ساتھ ViewModel، Repository اور UseCase کی جانچ کے لیے استعمال ہوتا ہے۔ چونکہ یہ کلاسز Android سیاق و سباق کے بغیر JVM پر چلتی ہیں، Mockito ان کے انحصار — Room DAO، Retrofit API، SharedPreferences — کو پیش قیاسی رویے والے stubs سے بدل دیتا ہے۔

Mockito کے لیے Gradle سیٹ اپ

Android پروجیکٹ میں Mockito شامل کرنے کے لیے، صرف mockito-core یا mockito-inline انحصار شامل کریں (مؤخر الذکر فائنل کلاسز اور جامد میتھڈز کے mocking کو سپورٹ کرتا ہے)۔ ورژن 5.12.0 (2024) Java 21 سپورٹ اور بہتر JUnit 5 انضمام شامل کرتا ہے۔

// build.gradle.kts (module)
dependencies {
    testImplementation("org.mockito:mockito-core:5.12.0")
    testImplementation("org.mockito:mockito-junit-jupiter:5.12.0")
}

Mockito اور PowerMock: متروک پریکٹس

پہلے، جامد میتھڈز اور کنسٹرکٹرز کے mocking کے لیے PowerMock — ایک توسیع جو بائٹ کوڈ انسٹرومینٹیشن کے ذریعے کام کرتی تھی — کی ضرورت تھی۔ Mockito 5.x سے mockito-inline کے ساتھ، یہ صلاحیت براہ راست شامل ہے: mockStatic(ClassName.class) اضافی لائبریریوں کے بغیر جامد میتھڈز کے mocking کی اجازت دیتا ہے۔

Mockito کے ساتھ ViewModel کی جانچ

ایک عام منظرنامہ: ایک ViewModel ریپوزٹری میتھڈ کو کال کرتا ہے اور نتیجہ کو UI حالت میں تبدیل کرتا ہے۔ Mockito ریپوزٹری کو بدل دیتا ہے، اور ٹیسٹ جانچتا ہے کہ ViewModel کامیاب جواب اور غلطی دونوں کو درست طریقے سے ہینڈل کرتا ہے۔ Clean Architecture استعمال کرتے وقت، ہر پرت کے لیے mocks بنائے جاتے ہیں: DataSource، Repository اور UseCase — یہ ہر پرت کو الگ تھلگ جانچنے کی اجازت دیتا ہے۔

• کامیابی کی صورت — when(repo.getData()).thenReturn(Result.success(data)) → state = Success(data) کی جانچ کریں۔
• غلطی کی صورت — when(repo.getData()).thenReturn(Result.error(exception)) → state = Error(message) کی جانچ کریں۔
• لوڈنگ حالت — verify کریں کہ ViewModel نے ریپوزٹری کو کال کرنے سے پہلے isLoading = true سیٹ کیا۔