موبائل ایپلیکیشنز میں UI ٹیسٹنگ: یہ کیا ہے، اقسام اور کیسے کی جاتی ہے

UI ٹیسٹنگ کیا ہے؟

UI ٹیسٹنگ خودکار جانچ کی ایک قسم ہے جس میں ٹیسٹ کوڈ ایپلیکیشن کے گرافیکل انٹرفیس کے ساتھ بالکل اسی طرح تعامل کرتا ہے جیسے کوئی حقیقی صارف کرے گا۔ ٹیسٹ اسکرین پر ایک عنصر — بٹن، ٹیکسٹ فیلڈ، فہرست — ڈھونڈتا ہے، اس پر ایک عمل انجام دیتا ہے اور متوقع انٹرفیس ردعمل کی تصدیق کرتا ہے۔ مثال کے طور پر، غلط پاس ورڈ درج کرنے کے بعد، UI ٹیسٹ جانچتا ہے کہ اسکرین پر صحیح متن کے ساتھ خرابی کا پیغام ظاہر ہوتا ہے۔

UI ٹیسٹوں اور آٹومیشن کی دیگر اقسام کے درمیان بنیادی فرق یہ ہے کہ وہ ایپلیکیشن کی اندرونی APIs کے ذریعے نہیں بلکہ آپریٹنگ سسٹم کی Accessibility پرت کے ذریعے کام کرتے ہیں۔ اس کا مطلب ہے کہ UI ٹیسٹ انٹرفیس کو بالکل اسی طرح دیکھتے ہیں جیسے صارف اور اسکرین ریڈر دیکھتے ہیں۔ اس کی بدولت، UI ٹیسٹ نہ صرف فعالیت بلکہ عناصر کی رسائی — WCAG کی ضروریات کی تعمیل — کی بھی جانچ کرتے ہیں۔

JetBrains Developer Ecosystem 2023 سروے کے مطابق، 58% موبائل ٹیمیں اپنی CI/CD پائپ لائن میں UI ٹیسٹ استعمال کرتی ہیں۔ تجارتی منصوبوں میں اوسط UI ٹیسٹ کوریج ایپلیکیشن اسکرینوں کا 30–40% ہے۔ UI ٹیسٹ والے منصوبوں کو انٹرفیس کریش سے متعلق ایپ اسٹورز میں 25% کم منفی جائزے ملتے ہیں۔

UI ٹیسٹنگ یونٹ ٹیسٹنگ سے کیسے مختلف ہے

UI ٹیسٹوں اور یونٹ ٹیسٹوں کے درمیان بنیادی فرق تجرید کی سطح ہے۔ یونٹ ٹیسٹ انفرادی کلاسز اور فنکشنز کے ساتھ کام کرتے ہیں جو Android یا iOS فریم ورک سے الگ تھلگ ہوتے ہیں۔ وہ ایمولیٹر شروع کیے بغیر JVM پر (Android کے لیے) چلتے ہیں اور ملی سیکنڈ لیتے ہیں۔ UI ٹیسٹ حقیقی ڈیوائس یا ایمولیٹر پر چلتے ہیں، سسٹم سروسز کے ساتھ تعامل کرتے ہیں اور فی منظرنامہ سیکنڈ یا منٹ لیتے ہیں۔

ٹیسٹوں کا ہدف سامعین بھی مختلف ہوتا ہے۔ UI ٹیسٹ اینڈ ٹو اینڈ صارف منظرناموں کی جانچ کرتے ہیں — رجسٹریشن، آرڈر دینا، تلاش۔ یونٹ ٹیسٹ کاروباری منطق کا احاطہ کرتے ہیں: حساب، توثیق، ڈیٹا کی تبدیلی۔ UI ٹیسٹ ٹیکس کے حساب کی درستگی کی جانچ نہیں کرتا — یہ جانچتا ہے کہ کل رقم اسکرین پر ظاہر ہوتی ہے۔ حساب خود یونٹ ٹیسٹ کے ذریعے تصدیق شدہ ہے۔

Google Testing Blog (2020) کے مطابق، کسی منصوبے میں ٹیسٹوں کا بہترین تناسب ٹیسٹ پیرامڈ کے اصول کی پیروی کرتا ہے: 70% یونٹ ٹیسٹ، 20% انٹیگریشن ٹیسٹ اور 10% UI ٹیسٹ۔ UI ٹیسٹوں کے حق میں اس تناسب کی خلاف ورزی کرنے سے چلنے کا وقت بڑھ جاتا ہے اور ٹیسٹ سوٹ نازک ہو جاتا ہے، کیونکہ UI ٹیسٹ اسکرین لے آؤٹ میں تبدیلیوں کے لیے حساس ہوتے ہیں۔

UI ٹیسٹنگ کے لیے فریم ورک

Android کے لیے، غالب فریم ورک Espresso ہے — Google کی لائبریری جو AndroidX Test میں شامل ہے۔ Espresso خود بخود UI تھریڈ کے ساتھ ہم آہنگ ہو جاتا ہے، اگلی جانچ سے پہلے اینیمیشنز اور پس منظر کے کاموں کے مکمل ہونے کا انتظار کرتا ہے۔ Jetpack Compose کے لیے، Compose UI Test ایکسٹینشن استعمال کی جاتی ہے، جو روایتی ویو شناخت کنندگان کی بجائے semantic nodes کے ذریعے کام کرتی ہے۔

iOS کے لیے، بنیادی ٹول XCUITest ہے، جو Xcode کا حصہ ہے۔ ٹیسٹ Swift میں لکھے جاتے ہیں اور عناصر کو تلاش کرنے کے لیے Accessibility شناخت کنندگان استعمال کرتے ہیں۔ XCUITest ریکارڈ فنکشن کے ذریعے ٹیسٹ ریکارڈنگ اور xcodebuild کے ذریعے CI سسٹمز کے ساتھ انضمام کی حمایت کرتا ہے۔ کراس پلیٹ فارم منصوبوں کے لیے، Appium استعمال کیا جاتا ہے، جو WebDriver پروٹوکول پر مبنی ہے اور کم سے کم کوڈ تبدیلیوں کے ساتھ Android اور iOS پر ایک جیسے ٹیسٹ چلانے کی اجازت دیتا ہے۔

Espresso اور Compose UI Test

Espresso onView اور وسائل کی ID شناخت کنندگان کے ذریعے روایتی ویو سسٹم کے ساتھ کام کرتا ہے۔ Compose UI Test ایک semantic پرت استعمال کرتا ہے، جس سے ٹیسٹ ویو درجہ بندی پر کم انحصار کرتے ہیں۔ مثال کے طور پر، Espresso میں بٹن تلاش کرنا: onView(withId(R.id.submit))، Compose میں: onNodeWithTag(“submit”)۔ Compose ٹیسٹ خود بخود دوبارہ تشکیل کو سنبھالتے ہیں اور واضح غیر فعال حالت کے انتظار کی ضرورت نہیں ہوتی۔

iOS کے لیے XCUITest

XCUITest داخلی نقطہ کے طور پر XCUIApplication استعمال کرتا ہے۔ ہر انٹرفیس عنصر Accessibility خصوصیات کے ذریعے پایا جاتا ہے: پروگراماتی رسائی کے لیے accessibilityIdentifier اور VoiceOver کے لیے accessibilityLabel۔ فریم ورک Xcode کے ریکارڈ فنکشن کے ذریعے ٹیسٹ ریکارڈنگ کی حمایت کرتا ہے — ڈویلپر سمیلیٹر پر اعمال انجام دیتا ہے اور Xcode ٹیسٹ کوڈ تیار کرتا ہے۔ تیار ٹیسٹ xcodebuild test کے ذریعے چلائے جاتے ہیں۔

کراس پلیٹ فارم حل

Appium WebDriver پروٹوکول پر مبنی ہے اور کسی بھی زبان کی حمایت کرتا ہے: Java، Python، JavaScript۔ عناصر کی تلاش کی حکمت عملیوں میں id، xpath، class name اور accessibility id شامل ہیں۔ Appium کے لیے سرور انسٹالیشن اور Desired Capabilities — platformName، deviceName، appPackage — کی تشکیل ضروری ہے۔ ایک متبادل Maestro ہے، جو YAML منظرنامے استعمال کرتا ہے اور ٹیسٹ کوڈ کمپائلیشن کی ضرورت نہیں ہوتی۔

• Espresso — onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed()))
• XCUITest — app.buttons[“loginButton”].tap(); XCTAssertTrue(app.staticTexts[“welcome”].exists)
• Appium — driver.findElement(By.id(“com.example:id/button”)).click()
• Detox — React Native کے لیے Wix کا فریم ورک، JS تھریڈ کے ساتھ ہم آہنگ ہوتا ہے
• Maestro — YAML منظرناموں والا جدید ٹول جس میں کوڈ لکھنے کی ضرورت نہیں

UI ٹیسٹوں کے لیے کوڈ کی مثالیں

آئیے تین مختلف فریم ورکس پر ایک ہی منظرنامہ — ایپلیکیشن میں لاگ ان — کے لیے UI ٹیسٹ دیکھتے ہیں: Android کے لیے Espresso، iOS کے لیے XCUITest اور کراس پلیٹ فارم طریقہ کے لیے Appium۔ منظرنامہ: لاگ ان اور پاس ورڈ درج کریں، لاگ ان بٹن دبائیں، خوش آمدید پیغام کی نمائش کی تصدیق کریں۔

Android: Espresso

Espresso ٹیسٹ کسی عنصر کو اس کے شناخت کنندہ سے تلاش کرنے کے لیے onView اور عمل انجام دینے کے لیے perform استعمال کرتا ہے۔ isDisplayed میچر کے ساتھ check طریقہ تصدیق کرتا ہے کہ عنصر اسکرین پر نظر آ رہا ہے۔

@RunWith(AndroidJUnit4::class)
class LoginUiTest {

    @Rule
    @JvmField
    val composeTestRule = createComposeRule()

    @Test
    fun login_withValidCredentials_showsWelcome() {
        composeTestRule
            .onNodeWithTag("emailField")
            .performTextInput("user@example.com")
        composeTestRule
            .onNodeWithTag("passwordField")
            .performTextInput("secret123")
        composeTestRule
            .onNodeWithTag("loginButton")
            .performClick()
        composeTestRule
            .onNodeWithText("خوش آمدید، صارف!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest Accessibility شناخت کنندگان کے ذریعے انٹرفیس عناصر تک رسائی کے لیے XCUIApplication استعمال کرتا ہے۔ tap() اور exists طریقے تعامل اور تصدیق فراہم کرتے ہیں۔

class LoginUITests: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLogin_withValidCredentials_showsWelcome() {
        app.textFields["emailField"].tap()
        app.textFields["emailField"].typeText("user@example.com")
        app.secureTextFields["passwordField"].tap()
        app.secureTextFields["passwordField"].typeText("secret123")
        app.buttons["loginButton"].tap()
        XCTAssertTrue(app.staticTexts["Welcome, User!"].exists)
    }
}

UI ٹیسٹنگ کے بہترین طریقے

پہلا اصول — عناصر کو تلاش کرنے کے لیے ٹیکسٹ لیبل کی بجائے Accessibility شناخت کنندگان استعمال کریں۔ بٹن کا متن لوکلائزیشن کے دوران بدل سکتا ہے، جبکہ شناخت کنندہ مستحکم رہتا ہے۔ Android میں، یہ contentDescription خاصیت ہے؛ iOS میں — accessibilityIdentifier۔ یہ طریقہ ٹیسٹوں کو انٹرفیس زبان سے آزاد بناتا ہے اور کاپی رائٹنگ تبدیل ہونے پر دیکھ بھال کے اخراجات کم کرتا ہے۔

sleep() اور مقررہ تاخیر سے بچیں — فریم ورک کے بلٹ ان انتظار کے طریقہ کار استعمال کریں۔ Espresso خود بخود اینیمیشنز اور پس منظر کے کاموں کے مکمل ہونے کا انتظار کرتا ہے۔ XCUITest ٹائم آؤٹ کے ساتھ XCTAssertTrue فراہم کرتا ہے۔ واضح توقف ٹیسٹوں کو سست اور غیر مستحکم بناتا ہے، خاص طور پر CI ماحول میں سست آلات پر۔

ٹیسٹوں کو اہمیت کے مطابق گروپ کریں: سموک ٹیسٹ (3–5 اہم منظرنامے) ہر کمٹ پر چلتے ہیں، مکمل UI ٹیسٹ سوٹ ریلیز سے پہلے چلتا ہے۔ Google Testing Blog (2022) کے مطابق، CI میں 30 منٹ سے زیادہ لینے والے UI ٹیسٹ چلانے کی تعدد کو 40% کم کر دیتے ہیں، جس سے ابتدائی رجریشن کا پتہ لگانے کے آلے کے طور پر ان کی تاثیر کم ہو جاتی ہے۔

UI ٹیسٹوں کی حدود اور ان پر قابو پانے کے طریقے

UI ٹیسٹوں کی کئی حدود ہیں۔ لے آؤٹ تبدیلیوں کے لیے حساسیت: شناخت کنندہ، درجہ بندی یا عنصر کی قسم تبدیل کرنے سے ٹیسٹ ٹوٹ جاتا ہے چاہے فعالیت میں کوئی تبدیلی نہ ہو۔ حل Page Object پیٹرن استعمال کرنا ہے، جو عنصر سلیکٹرز کو علیحدہ کلاسز میں مرکزی بناتا ہے۔ لے آؤٹ تبدیل ہونے پر، درجنوں ٹیسٹوں کی بجائے صرف ایک Page Object فائل درست کی جاتی ہے۔

عملدرآمد کا وقت: حقیقی ڈیوائس یا ایمولیٹر پر چلنے میں یونٹ ٹیسٹ سے 10–50 گنا زیادہ وقت لگتا ہے۔ حل Firebase Test Lab یا AWS Device Farm کے ذریعے متعدد آلات پر UI ٹیسٹ متوازی طور پر چلانا ہے۔ عدم استحکام CI رن کا ایک عام مسئلہ ہے جو اینیمیشنز، نیٹ ورک تاخیر یا ایمولیٹر کی حالت کی وجہ سے ہوتا ہے۔ عدم استحکام سے نمٹنے کے لیے، ناکام ٹیسٹوں کی خودکار دوبارہ کوشش اور ہر ٹیسٹ منظرنامے کے استحکام کا تجزیہ استعمال کیا جاتا ہے۔