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 matchers استعمال کرتا ہے۔

ViewAssertions: حالت کی جانچ

ViewAssertions تصدیق کرتے ہیں کہ View ایک مخصوص حالت میں ہے۔ بنیادی طریقہ — matches(matcher) — چیک کرتا ہے کہ عنصر دیے گئے میچر سے مطابقت رکھتا ہے۔ اضافی طور پر، Espresso doesNotExist() (عنصر موجود نہیں) اور selectedDescendantsMatch() (نیسٹڈ عناصر کی جانچ) فراہم کرتا ہے۔

عام جانچیں

UI ٹیسٹوں میں سب سے زیادہ بار بار جانچیں: عنصر ظاہر ہے (isDisplayed)، عنصر میں مخصوص متن ہے (withText)، عنصر فعال ہے (isEnabled)، عنصر منتخب نہیں ہے (isNotChecked)۔ ہر جانچ ناکامی پر ایک تفصیلی استثنا پھینکتی ہے — اسکرین پر View درجہ بندی سمیت۔ یہ ڈیبگنگ کو آسان بناتا ہے: خرابی کا پیغام دکھاتا ہے کہ جانچ کے وقت اسکرین پر اصل میں کون سے عناصر تھے۔

اپنی مرضی کے ViewAssertions

اگر معیاری جانچیں ناکافی ہیں، تو ViewAssertion انٹرفیس کے ذریعے اپنی مرضی کی جانچ بنائی جا سکتی ہے۔ اپنی مرضی کا اثبات ایک 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 استعمال کیا جاتا ہے — متعدد ایمولیٹروں کے درمیان ٹیسٹ تقسیم کرنا۔