موبائل ڈیولپمنٹ میں ٹیسٹنگ: یہ کیا ہے، کتنی اقسام ہیں اور کیسے منظم کریں

ٹیسٹنگ کی سطحیں: Unit، Integration، E2E

یونٹ ٹیسٹنگ

یونٹ ٹیسٹ موبائل ایپ ٹیسٹنگ کی بنیاد ہیں۔ وہ کوڈ کی سب سے چھوٹی اکائی — ایک واحد فنکشن، طریقہ یا کلاس کو سسٹم کے باقی حصوں سے الگ کر کے تصدیق کرتے ہیں۔ موبائل ڈیولپمنٹ میں، یونٹ ٹیسٹ JUnit (Android) اور XCTest (iOS) میں لکھے جاتے ہیں۔ ایک اچھا یونٹ ٹیسٹ تیز، آزاد اور دہرایا جانے والا ہونا چاہیے — اسے نیٹ ورک، ڈیٹا بیس یا UI اجزاء پر منحصر نہیں ہونا چاہیے۔ علیحدگی کے لیے ٹیسٹ ڈبلز استعمال کیے جاتے ہیں: موک، سٹب اور فیک۔

Mockito (Java/Kotlin) اور MockK (Kotlin-first) Android پر موک آبجیکٹ بنانے کے لیے مشہور لائبریریاں ہیں۔ iOS پر، OCMock، Cuckoo یا دستی پروٹوکول استعمال کیے جاتے ہیں۔ قاعدہ: یونٹ ٹیسٹ کو کاروباری منطق اور ڈیٹا ماڈلز کا احاطہ کرنا چاہیے۔ UI ٹیسٹ کو یونٹ ٹیسٹ کی نقل نہیں کرنی چاہیے — وہ انٹرفیس کے ساتھ صارف کے تعامل کی تصدیق کرتے ہیں۔

انٹیگریشن ٹیسٹنگ

انٹیگریشن ٹیسٹ اجزاء کے درمیان تعامل کی تصدیق کرتے ہیں: ڈیٹا بیس کے ساتھ ریپوزٹری، API سروس کے ساتھ ViewModel، اسکرینوں کے درمیان نیویگیشن۔ یونٹ ٹیسٹ کے برعکس، انٹیگریشن ٹیسٹ حقیقی یا حقیقت کے قریب انحصار استعمال کرتے ہیں (مثال کے طور پر، میموری میں ڈیٹا بیس یا موک سرور)۔ Robolectric ایمولیٹر کے بغیر JVM پر Android ٹیسٹ چلانے کا فریم ورک ہے، جو انٹیگریشن ٹیسٹ کو 10 گنا تیز کرتا ہے۔

سنیشاٹ ٹیسٹ (گولڈن ٹیسٹ) ایک خاص قسم کے انٹیگریشن ٹیسٹ ہیں جو رینڈر کردہ UI جزو کا موازنہ ریفرنس امیج (سنیشاٹ) سے کرتے ہیں۔ اگر ظاہری شکل بدل جائے تو ٹیسٹ ناکام ہو جاتا ہے — ڈیولپر دیکھتا ہے کہ کیا بدلا۔ Facebook SnapshotTestCase (iOS) اور Shot (Android) سنیشاٹ ٹیسٹنگ کے مشہور ٹولز ہیں۔

E2E اور UI ٹیسٹنگ

E2E ٹیسٹ (اینڈ ٹو اینڈ) شروع سے آخر تک مکمل صارف منظرنامے کی تصدیق کرتے ہیں: ایپ لانچ، لاگ ان، کارروائی کرنا، نتیجہ چیک کرنا۔ UI ٹیسٹ E2E کا ایک ذیلی سیٹ ہے جو انٹرفیس پر مرکوز ہے۔ ٹولز: Espresso (Android)، XCUITest (iOS)، Detox (React Native)۔ E2E ٹیسٹ سب سے سست ہوتے ہیں، اس لیے انہیں CI پر الگ سے چلایا جاتا ہے — عام طور پر راتوں رات بلڈ پر۔

iOS ٹولز: XCTest اور XCUITest

XCTest

XCTest موبائل ایپلیکیشنز کے یونٹ ٹیسٹنگ کے لیے Apple کا بلٹ ان فریم ورک ہے۔ XCTestRunner سمیلیٹر یا حقیقی ڈیوائس پر ٹیسٹ چلاتا ہے۔ ٹیسٹ XCTestCase سے وراثت پاتے ہیں، تیاری اور صفائی کے لیے setUp اور tearDown شامل کرتے ہیں۔ XCTest میں تصدیق کے لیے XCTAssert (XCTAssertEqual، XCTAssertNil، XCTAssertTrue) اور غیر متزامن کارروائیوں کے انتظار کے لیے XCTWaiter شامل ہے۔

ایک سادہ XCTest ٹیسٹ کی مثال: User ماڈل بنانا، ابتدا کی درستگی، نام کی فارمیٹنگ اور عمر کے حساب کی تصدیق۔ کوڈ کوریج Xcode میں دکھاتا ہے کہ کوڈ کی کون سی لائنیں ٹیسٹ سے کور ہوئی ہیں — تجارتی منصوبوں کا ہدف: کاروباری منطق کا کم از کم 70–80% کوریج۔ XCTest xcodebuild test کے ذریعے Xcode Server اور CI سسٹمز کے ساتھ مربوط ہے۔

XCUITest

XCUITest UI ٹیسٹنگ کے لیے Apple کا فریم ورک ہے۔ یہ رسائی شناخت کنندگان کے ذریعے کام کرتا ہے: XCUIElementQuery بٹن، انپٹ فیلڈ، ٹیبل کو لیبل، شناخت کنندہ یا قسم کی بنیاد پر ڈھونڈتا ہے۔ XCUITest کارروائیوں کا سلسلہ ریکارڈ کرتا ہے (ریکارڈ/پلے بیک) اور ٹیسٹ کوڈ تیار کرتا ہے۔ اہم: مستحکم ٹیسٹ آپریشن کے لیے تمام UI عناصر کے پاس accessibilityIdentifier ہونا چاہیے۔

Android ٹولز: JUnit، Espresso، Robolectric

JUnit اور Mockito

JUnit Java/Kotlin پر موبائل ایپلیکیشنز کے ماڈیولر ٹیسٹنگ کے لیے بنیادی فریم ورک ہے۔ Android پر، JUnit 4 (تازہ ترین مستحکم ورژن 4.13.2) اور نئے منصوبوں کے لیے JUnit 5 استعمال کیا جاتا ہے۔ Mockito موک آبجیکٹ بنانے کی لائبریری ہے: when(mock.method()).thenReturn(value) — ٹیسٹ شدہ کلاس کو انحصار سے الگ کرنے کا معیاری نمونہ۔

Android کے لیے JUnit ٹیسٹ کی مثال:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso اور UI Automator

Espresso Android UI ٹیسٹ کے لیے Google کا فریم ورک ہے۔ Espresso خود بخود UI تھریڈ کے ساتھ ہم آہنگ ہو جاتا ہے: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed()))۔ Espresso بلٹ ان آئیڈل اسٹیٹ ویٹنگ کی بدولت لکھنے میں آسان اور مستحکم ہے۔ UI Automator کراس ایپلیکیشن ٹیسٹ کے لیے فریم ورک ہے جو سسٹم عناصر (اجازت ڈائیلاگ، نوٹیفکیشن شیڈ) کے ساتھ تعامل کر سکتا ہے۔

کراس پلیٹ فارم ٹولز: Detox، Appium

React Native کے لیے Detox

Detox Wix کی طرف سے React Native موبائل ایپلیکیشنز کی جانچ کے لیے گرے باکس E2E فریم ورک ہے۔ Detox ایک ہی ٹیسٹ کوڈ بیس سے دونوں پلیٹ فارمز پر کام کرتا ہے، اندرونی طور پر Espresso (Android) اور XCUITest (iOS) استعمال کرتا ہے۔ Detox خود بخود ایپ کے بیکار ہونے (کوئی اینیمیشن، نیٹ ورک درخواستیں، ٹائمر نہیں) تک انتظار کرتا ہے اور تب ہی اگلی کارروائی کرتا ہے۔

Appium

Appium ایک آفاقی کراس پلیٹ فارم فریم ورک ہے جو Android، iOS، ویب اور ہائبرڈ ایپلیکیشنز کو سپورٹ کرتا ہے۔ Appium WebDriver پروٹوکول استعمال کرتا ہے اور کسی بھی پروگرامنگ زبان (Java، Python، JS، Ruby) کو سپورٹ کرتا ہے۔ Appium Server ایک HTTP سرور کے طور پر کام کرتا ہے جو کمانڈز کو مقامی UI Automator / XCUITest کمانڈز میں ترجمہ کرتا ہے۔ Appium کا بنیادی نقصان رفتار ہے: ٹیسٹ مقامی Espresso یا XCUITest کے مقابلے میں آہستہ چلتے ہیں۔

TDD اور BDD: ٹیسٹنگ کے طریقہ کار

TDD: ٹیسٹ سے چلنے والی ڈیولپمنٹ

TDD ایک موبائل ایپ ٹیسٹنگ کا طریقہ کار ہے جہاں نفاذ کوڈ سے پہلے ٹیسٹ لکھا جاتا ہے۔ Red-Green-Refactor چکر: (1) ایک ٹیسٹ لکھیں جو ناکام ہو (Red)، (2) ٹیسٹ پاس کرنے کے لیے کم سے کم کوڈ لکھیں (Green)، (3) ٹیسٹ پاس رکھتے ہوئے کوڈ کو ری فیکٹر کریں۔ TDD نئی فعالیت کے لیے 100% ٹیسٹ کوریج اور صاف ستھرا فن تعمیر فراہم کرتا ہے، کیونکہ ٹیسٹ ضرورت کی پہلی تفصیلات ہے۔

BDD: رویے سے چلنے والی ڈیولپمنٹ

BDD TDD کی توسیع ہے جہاں ٹیسٹ قدرتی زبان میں Given-When-Then فارمیٹ میں لکھے جاتے ہیں۔ Given (سیاق) — When (عمل) — Then (متوقع نتیجہ)۔ BDD ٹیسٹ ٹیم کے تمام اراکین کے لیے قابل فہم ہیں: ڈیولپرز، ٹیسٹرز، تجزیہ کار اور کلائنٹ۔ Mock بمقابلہ Stub بمقابلہ Fake: Mock تعامل کی تصدیق کرتا ہے (کیا طریقہ بلایا گیا)، Stub مقررہ ڈیٹا لوٹاتا ہے، Fake ایک آسان کام کرنے والا نفاذ ہے (مثلاً، میموری میں DB)۔ IT Sectr میں، ہم اہم کاروباری منطق کے لیے TDD اور قبولیت کے منظرناموں کے لیے BDD استعمال کرتے ہیں۔

ٹیسٹ ڈبلز ان اشیاء کا عام نام ہے جو ٹیسٹوں میں حقیقی انحصار کی جگہ لیتی ہیں۔ چار اقسام ہیں: Dummy (پیرامیٹر بھرنے کے لیے، استعمال نہیں ہوتی)، Stub (مقررہ اقدار لوٹاتی ہے)، Spy (تصدیق کے لیے کالز ریکارڈ کرتی ہے)، Mock (متوقع کالز پہلے سے متعین کرتی ہے)۔ فرق کو سمجھنا مناسب ٹیسٹ ڈیزائن کے لیے بہت اہم ہے۔

CI/CD اور Device Farm

CI/CD میں ٹیسٹ آٹومیشن

CI/CD — مسلسل انضمام اور مسلسل ترسیل: ہر کوڈ تبدیلی پر موبائل ایپلیکیشنز کو خود بخود بنانے اور جانچنے کا عمل۔ موبائل ڈیولپمنٹ میں، CI/CD پائپ لائن میں شامل ہیں: لنٹنگ، یونٹ ٹیسٹ، انٹیگریشن ٹیسٹ، APK/IPA بلڈ اور UI ٹیسٹ۔ GitHub Actions اور Bitrise موبائل CI/CD کے مشہور پلیٹ فارم ہیں۔ ٹیسٹ تیزی سے چلنے چاہئیں: یونٹ ٹیسٹ 1–2 منٹ میں، انٹیگریشن 5–10 میں، UI ٹیسٹ 15–30 منٹ میں۔

Device Farm

Device Farm جانچ کے لیے حقیقی آلات کا فارم ہے۔ Firebase Test Lab (Android) اور Xcode Cloud (iOS) سینکڑوں ڈیوائس ماڈلز تک کلاؤڈ رسائی فراہم کرتے ہیں۔ Device Farm ان مسائل کو ظاہر کرتا ہے جو ایمولیٹرز پر نظر نہیں آتے: مختلف اسکرین سائز، پرانے آلات پر کارکردگی، مطابقت کے مسائل۔ IT Sectr میں، ہم Android کے لیے Firebase Test Lab اور iOS کے لیے Xcode Cloud باقاعدگی سے استعمال کرتے ہیں۔