মোবাইল অ্যাপ্লিকেশনে UI টেস্টিং: এটি কী, প্রকারভেদ এবং কীভাবে করা হয়

UI টেস্টিং কী?

UI টেস্টিং এক ধরনের স্বয়ংক্রিয় পরীক্ষা যেখানে টেস্ট কোড অ্যাপ্লিকেশনের গ্রাফিক্যাল ইন্টারফেসের সাথে ঠিক তেমনই ইন্টারঅ্যাক্ট করে যেমন একজন প্রকৃত ব্যবহারকারী করবে। টেস্টটি স্ক্রিনে একটি উপাদান খুঁজে পায় — বাটন, টেক্সট ফিল্ড, তালিকা — এটির উপর একটি ক্রিয়া সম্পাদন করে এবং প্রত্যাশিত ইন্টারফেস প্রতিক্রিয়া যাচাই করে। উদাহরণস্বরূপ, ভুল পাসওয়ার্ড প্রবেশ করানোর পর, একটি UI টেস্ট পরীক্ষা করে যে সঠিক টেক্সট সহ একটি ত্রুটি বার্তা স্ক্রিনে উপস্থিত হয়েছে কিনা।

UI টেস্ট এবং অন্যান্য ধরণের অটোমেশনের মধ্যে প্রধান পার্থক্য হল এগুলি অ্যাপ্লিকেশনের অভ্যন্তরীণ API-এর মাধ্যমে নয় বরং অপারেটিং সিস্টেমের অ্যাক্সেসিবিলিটি স্তর-এর মাধ্যমে কাজ করে। এর অর্থ হল 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 এক্সটেনশন ব্যবহার করা হয় যা ঐতিহ্যবাহী ভিউ আইডেন্টিফায়ারের পরিবর্তে সিম্যান্টিক নোডের মাধ্যমে কাজ করে।

iOS-এর জন্য, প্রাথমিক টুল হল XCUITest, যা Xcode-এর অংশ। টেস্টগুলি Swift-এ লেখা হয় এবং উপাদান খুঁজতে অ্যাক্সেসিবিলিটি আইডেন্টিফায়ার ব্যবহার করে। XCUITest রেকর্ড ফাংশনের মাধ্যমে টেস্ট রেকর্ডিং এবং xcodebuild-এর মাধ্যমে CI সিস্টেমের সাথে সংহতকরণ সমর্থন করে। ক্রস-প্ল্যাটফর্ম প্রকল্পের জন্য, Appium ব্যবহার করা হয়, যা WebDriver প্রোটোকলের উপর ভিত্তি করে এবং ন্যূনতম কোড পরিবর্তনের সাথে Android এবং iOS-এ একই টেস্ট চালানোর অনুমতি দেয়।

Espresso এবং Compose UI Test

Espresso onView এবং রিসোর্স আইডি আইডেন্টিফায়ারের মাধ্যমে ঐতিহ্যবাহী ভিউ সিস্টেমের সাথে কাজ করে। Compose UI Test একটি সিম্যান্টিক স্তর ব্যবহার করে, যা টেস্টগুলিকে ভিউ হায়ারার্কির উপর কম নির্ভরশীল করে। উদাহরণস্বরূপ, Espresso-তে বাটন খুঁজতে: onView(withId(R.id.submit)), Compose-এ: onNodeWithTag(“submit”)। Compose টেস্টগুলি স্বয়ংক্রিয়ভাবে পুনর্গঠন পরিচালনা করে এবং স্পষ্ট নিষ্ক্রিয় অবস্থা অপেক্ষার প্রয়োজন হয় না।

iOS-এর জন্য XCUITest

XCUITest প্রবেশ বিন্দু হিসাবে XCUIApplication ব্যবহার করে। প্রতিটি ইন্টারফেস উপাদান অ্যাক্সেসিবিলিটি বৈশিষ্ট্যের মাধ্যমে পাওয়া যায়: প্রোগ্রামেটিক অ্যাক্সেসের জন্য 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 অ্যাক্সেসিবিলিটি আইডেন্টিফায়ারের মাধ্যমে ইন্টারফেস উপাদানগুলিতে অ্যাক্সেস করতে 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 টেস্টিং-এর সেরা অনুশীলন

প্রথম নীতি — উপাদান খুঁজতে টেক্সট লেবেলের পরিবর্তে অ্যাক্সেসিবিলিটি আইডেন্টিফায়ার ব্যবহার করুন। বাটনের টেক্সট স্থানীয়করণের সময় পরিবর্তিত হতে পারে, যখন আইডেন্টিফায়ার স্থির থাকে। Android-এ, এটি contentDescription বৈশিষ্ট্য; iOS-এ — accessibilityIdentifier। এই পদ্ধতি টেস্টগুলিকে ইন্টারফেস ভাষা থেকে স্বাধীন করে এবং কপিরাইটিং পরিবর্তন করার সময় রক্ষণাবেক্ষণ খরচ কমায়।

sleep() এবং নির্দিষ্ট বিলম্ব এড়িয়ে চলুন — ফ্রেমওয়ার্কের অন্তর্নির্মিত অপেক্ষা প্রক্রিয়া ব্যবহার করুন। Espresso স্বয়ংক্রিয়ভাবে অ্যানিমেশন এবং ব্যাকগ্রাউন্ড কাজ শেষ হওয়ার অপেক্ষা করে। XCUITest টাইমআউট সহ XCTAssertTrue প্রদান করে। স্পষ্ট বিরতি টেস্টগুলিকে ধীর এবং অস্থির করে তোলে, বিশেষত CI পরিবেশে ধীর ডিভাইসে।

গুরুত্ব অনুসারে টেস্ট গ্রুপ করুন: স্মোক টেস্ট (3–5টি মূল পরিস্থিতি) প্রতিটি কমিটে চলে, সম্পূর্ণ UI টেস্ট স্যুট রিলিজের আগে চলে। Google Testing Blog (2022) অনুসারে, CI-তে 30 মিনিটের বেশি সময় নেওয়া UI টেস্ট চলার ফ্রিকোয়েন্সি 40% কমিয়ে দেয়, যা প্রাথমিক রিগ্রেশন সনাক্তকরণ সরঞ্জাম হিসাবে তাদের কার্যকারিতা হ্রাস করে।

UI টেস্টের সীমাবদ্ধতা এবং কীভাবে সেগুলি অতিক্রম করা যায়

UI টেস্টের বেশ কয়েকটি সীমাবদ্ধতা রয়েছে। লেআউট পরিবর্তনের প্রতি সংবেদনশীলতা: আইডেন্টিফায়ার, হায়ারার্কি বা উপাদানের ধরন পরিবর্তন করলে টেস্ট ভেঙে যায় এমনকি কার্যকারিতা অপরিবর্তিত থাকলেও। সমাধান হল পেজ অবজেক্ট প্যাটার্ন ব্যবহার করা, যা পৃথক ক্লাসে উপাদান নির্বাচককে কেন্দ্রীভূত করে। লেআউট পরিবর্তন হলে, ডজনখানেক টেস্টের পরিবর্তে একটি পেজ অবজেক্ট ফাইল সংশোধন করা হয়।

নির্বাহের সময়: বাস্তব ডিভাইস বা এমুলেটরে চালাতে ইউনিট টেস্টের তুলনায় 10–50 গুণ বেশি সময় লাগে। সমাধান হল Firebase Test Lab বা AWS Device Farm-এর মাধ্যমে একাধিক ডিভাইসে UI টেস্ট সমান্তরালভাবে চালানো। অস্থিরতা (flakiness) CI রানের একটি সাধারণ সমস্যা যা অ্যানিমেশন, নেটওয়ার্ক বিলম্ব বা এমুলেটরের অবস্থার কারণে ঘটে। অস্থিরতা মোকাবেলায়, ব্যর্থ টেস্টের স্বয়ংক্রিয় পুনরায় চেষ্টা এবং প্রতিটি টেস্ট পরিস্থিতির স্থিতিশীলতা বিশ্লেষণ ব্যবহার করা হয়।