Espresso — यह क्या है, कार्य सिद्धांत और इसका उपयोग कैसे करें

Espresso क्या है?

Espresso Android के लिए स्वचालित UI परीक्षण लिखने की एक लाइब्रेरी है, जो Google AndroidX Test का हिस्सा है। यह स्क्रीन पर View तत्वों को खोजने, उन पर क्रियाएँ करने (क्लिक, इनपुट, स्वाइप) और उनकी स्थिति जाँचने (प्रदर्शित, टेक्स्ट रखता है, सक्षम है) के लिए API प्रदान करती है।

Espresso की मुख्य विशेषता एप्लिकेशन के मुख्य थ्रेड के साथ स्वचालित सिंक्रनाइज़ेशन है। फ्रेमवर्क अगली जाँच करने से पहले सभी एसिंक्रोनस कार्यों (coroutines, AsyncTask, Handler) के पूरा होने की प्रतीक्षा करता है। यह रेस कंडीशन के कारण होने वाले अस्थिर परीक्षणों को समाप्त करता है और UI परीक्षणों को स्थिर और विश्वसनीय बनाता है — कोई भी परीक्षण Thread.sleep() या प्रतीक्षा लूप का उपयोग नहीं करता।

Espresso तीन-पैर वाले कुत्ते सिद्धांत का पालन करता है — एक परीक्षण में तीन चरण होते हैं: तत्व खोजें (ViewMatcher), क्रिया करें (ViewAction), परिणाम जाँचें (ViewAssertion)। तीनों चरणों को कॉल की श्रृंखला में लिखा जाता है: onView().perform().check()। यह अवधारणा परीक्षणों को पूर्वानुमेय और पढ़ने में आसान बनाती है — प्रत्येक परीक्षण स्पष्ट रूप से बताता है कि वह क्या खोजता है, क्या करता है और क्या जाँचता है।

Espresso कैसे काम करता है

आर्किटेक्चर Espresso तीन घटकों पर आधारित है: Espresso (प्रवेश बिंदु — स्थिर विधियाँ onView और onData), ViewMatchers (तत्व खोज), ViewActions (क्रियाएँ) और ViewAssertions (जाँच)। आंतरिक रूप से, फ्रेमवर्क UI थ्रेड के साथ सिंक्रनाइज़ेशन के लिए Idling Resource का उपयोग करता है।

मूल Espresso परीक्षण

सबसे सरल परीक्षण ID द्वारा बटन ढूँढता है, क्लिक करता है, और जाँचता है कि “हो गया” टेक्स्ट दिखाई देता है। परीक्षण के दृष्टिकोण से सभी संचालन सिंक्रोनस हैं — Espresso गारंटी देता है कि परीक्षण जारी रखने से पहले UI थ्रेड ने ईवेंट प्रोसेस करना पूरा कर लिया है। यह एक अंतर्निहित प्रतीक्षा तंत्र के माध्यम से प्राप्त होता है: onView तब तक परीक्षण निष्पादन को रोकता है जब तक UI निष्क्रिय न हो जाए।

@Test
fun buttonClick_showsSuccessText() {
    // ID द्वारा बटन खोजें और क्लिक करें
    onView(withId(R.id.button_submit))
        .perform(click())

    // जाँचें कि “हो गया” टेक्स्ट प्रदर्शित होता है
    onView(withText("हो गया"))
        .check(matches(isDisplayed()))
}

ActivityScenario नियम

Espresso परीक्षण लॉन्च करने के लिए, ActivityScenario (AndroidX Test) का उपयोग किया जाता है, जो एक विशिष्ट स्थिति में Activity बनाता है — चल रही, रोकी गई, या नष्ट की गई। ActivityScenario शुद्ध UI परीक्षण के अलावा Activity जीवनचक्र परीक्षण की अनुमति देता है। उदाहरण के लिए, आप जाँच सकते हैं कि स्क्रीन घुमाने (Activity पुनर्निर्माण) पर डेटा संरक्षित रहता है और नष्ट होने के बाद पुनर्स्थापित होता है।

ViewMatchers: UI तत्व खोजना

ViewMatchers Espresso.onView वर्ग की विधियों का एक सेट है जो विभिन्न मानदंडों द्वारा स्क्रीन पर Views खोजने की अनुमति देता है: संसाधन ID (R.id), टेक्स्ट, हिंट, पैरेंट तत्व और पदानुक्रम। यदि एक matcher अद्वितीय परिणाम नहीं देता है, तो matchers को allOf() का उपयोग करके जोड़ा जा सकता है।

मैचरों का संयोजन

यदि स्क्रीन पर कई समान तत्व हैं (जैसे, अलग-अलग टेक्स्ट वाले दो TextView), तो allOf का उपयोग करके मैचरों को जोड़ना सुविधाजनक है: onView(allOf(withId(R.id.title), withText(“नमस्ते”))). यह एकल तत्व चयन की गारंटी देता है। व्युत्क्रम संकारक — not() — तत्वों को खोज से बाहर करता है, और hasSibling() किसी ज्ञात तत्व के बगल में तत्व ढूँढता है।

ViewActions: UI के साथ इंटरैक्शन

ViewActions वे क्रियाएँ हैं जो Espresso मिले View पर करता है: click(), typeText(), clearText(), scrollTo(), swipeLeft() और अन्य। क्रियाएँ perform() विधि में पास की जाती हैं, जो एक साथ कई क्रियाएँ स्वीकार कर सकती है।

क्रिया श्रृंखला

perform() विधि vararg ViewAction स्वीकार करती है, जो एक तत्व पर क्रियाओं का क्रम निष्पादित करने की अनुमति देती है: फ़ील्ड साफ़ करें, नया टेक्स्ट दर्ज करें, कीबोर्ड बंद करें, और बटन दबाएँ। सभी क्रियाएँ सूचीबद्ध क्रम में निष्पादित होती हैं, और Espresso गारंटी देता है कि अगली क्रिया शुरू होने से पहले पिछली क्रिया पूरी हो गई है।

// EditText में टेक्स्ट दर्ज करें और बटन दबाएँ
onView(withId(R.id.edit_email))
    .perform(
        clearText(),
        typeText("user@example.com"),
        closeSoftKeyboard()
    )

onView(withId(R.id.button_login))
    .perform(click())

onData के माध्यम से जाँच

AdapterView (ListView, RecyclerView) के अंदर तत्वों के लिए, onView के बजाय onData() विधि का उपयोग किया जाता है। यह Views के बजाय एडॉप्टर डेटा के साथ काम करता है — मॉडल सामग्री द्वारा तत्व ढूँढता है और आगे की क्रियाओं के लिए संबंधित View लौटाता है। onData मॉडल डेटा फ़ील्ड द्वारा तत्व का पता लगाने के लिए hamcrest मैचर का उपयोग करता है।

ViewAssertions: स्थिति जाँच

ViewAssertions जाँचते हैं कि View एक विशिष्ट स्थिति में है। मूल विधि — matches(matcher) — जाँचती है कि तत्व दिए गए मैचर से मेल खाता है। इसके अतिरिक्त, Espresso doesNotExist() (तत्व अनुपस्थित है) और selectedDescendantsMatch() (नेस्टेड तत्वों की जाँच) प्रदान करता है।

सामान्य जाँच

UI परीक्षणों में सबसे सामान्य जाँच: तत्व प्रदर्शित है (isDisplayed), तत्व में विशिष्ट टेक्स्ट है (withText), तत्व सक्षम है (isEnabled), तत्व चयनित नहीं है (isNotChecked)। प्रत्येक जाँच विफलता पर विस्तृत अपवाद फेंकती है — जिसमें स्क्रीन पर View पदानुक्रम शामिल होता है। यह डिबगिंग को सरल बनाता है: त्रुटि संदेश दिखाता है कि जाँच के समय स्क्रीन पर वास्तव में कौन से तत्व थे।

कस्टम ViewAssertions

यदि मानक जाँच अपर्याप्त हैं, तो ViewAssertion इंटरफ़ेस के माध्यम से कस्टम जाँच बनाई जा सकती है। एक कस्टम assertion एक View प्राप्त करता है और प्रोग्रामेटिक रूप से उसकी स्थिति जाँच सकता है — उदाहरण के लिए, टेक्स्ट का रंग, पैडिंग, या कस्टम घटक की स्थिति जो मानक मैचर के माध्यम से उपलब्ध नहीं है।

// जाँच: TextView प्रदर्शित है और टेक्स्ट रखता है
onView(withId(R.id.text_welcome))
    .check(matches(isDisplayed()))
    .check(matches(withText("स्वागत है")))

// जाँच: तत्व प्रदर्शित नहीं है
onView(withId(R.id.progress_bar))
    .check(doesNotExist())

एसिंक्रोनस संचालन के लिए Idling Resources

Idling Resource एसिंक्रोनस संचालन के साथ परीक्षण को सिंक्रनाइज़ करने का Espresso तंत्र है। डिफ़ॉल्ट रूप से, Espresso Handler, AsyncTask और coroutines ( coroutinesIdlingResource के माध्यम से) की प्रतीक्षा करता है। यदि एप्लिकेशन कस्टम थ्रेड या कॉलबैक सेवाओं के माध्यम से पृष्ठभूमि कार्य करता है, तो कस्टम Idling Resource पंजीकृत करना आवश्यक है।

Coroutines के साथ उदाहरण

AndroidX Test 1.4.0 से शुरू, Espresso CoroutinesIdlingResource के माध्यम से coroutines का समर्थन करता है। परीक्षण UI जाँच करने से पहले सभी लॉन्च किए गए coroutines के पूरा होने की स्वचालित रूप से प्रतीक्षा करता है। अधिक जटिल परिदृश्यों के लिए, CountingIdlingResource का उपयोग किया जाता है — एक काउंटर जो कार्य शुरू होने पर बढ़ता है और पूरा होने पर घटता है।

// OkHttp के लिए IdlingResource पंजीकृत करें
class OkHttpIdlingResource(
    private val client: OkHttpClient
) : IdlingResource {

    private var isIdle = true
    private var watcher: IdlingResource.ResourceCallback? = null

    override fun getName() = "OkHttp"

    override fun isIdleNow() = isIdle

    override fun registerIdleTransitionCallback(
        callback: IdlingResource.ResourceCallback
    ) {
        watcher = callback
    }
}

Android प्रोजेक्ट में Espresso सेटअप

कनेक्शन Android प्रोजेक्ट में Espresso मॉड्यूल स्तर के build.gradle में निर्भरताएँ जोड़कर किया जाता है। Espresso AndroidX Test का हिस्सा है, इसलिए Espresso कोर, एक्सटेंशन और JUnit एकीकरण के लिए निर्भरताएँ निर्दिष्ट करना पर्याप्त है। परीक्षण src/androidTest निर्देशिका में रखे जाते हैं और AndroidJUnitRunner के माध्यम से भौतिक डिवाइस या एमुलेटर पर चलाए जाते हैं।

Gradle कॉन्फ़िगरेशन

न्यूनतम निर्भरता सेट में espresso-core (कोर), espresso-contrib (RecyclerView, Drawer, Picker के लिए अतिरिक्त मैचर) और runner (AndroidX टेस्ट रनर) शामिल हैं। सभी परीक्षण Android Test Orchestrator के माध्यम से एमुलेटर या भौतिक डिवाइस पर चलाए जाते हैं।

// build.gradle.kts (androidTest निर्भरताएँ)
android {
    defaultConfig {
        testInstrumentationRunner =
            "androidx.test.runner.AndroidJUnitRunner"
    }
}

dependencies {
    androidTestImplementation("androidx.test.espresso:espresso-core:3.6.1")
    androidTestImplementation("androidx.test.espresso:espresso-contrib:3.6.1")
    androidTestImplementation("androidx.test:runner:1.6.1")
    androidTestImplementation("androidx.test:rules:1.6.1")
}

CI पर परीक्षण चलाना

Espresso परीक्षण Google Android Test Orchestrator के माध्यम से चलाए जा सकते हैं, जो प्रत्येक परीक्षण को एक अलग प्रक्रिया में अलग करता है और चलाने के बीच स्थिति साफ़ करता है। यह पिछले परीक्षणों के अवशिष्ट डेटा के कारण होने वाले अस्थिर परीक्षणों को समाप्त करता है और CI सर्वरों पर स्थिरता बढ़ाता है। समानांतर निष्पादन के लिए, sharding का उपयोग किया जाता है — कई एमुलेटरों के बीच परीक्षण वितरित करना।