UI Automator: یہ کیا ہے، کلیدی تصورات اور یہ کیسے کام کرتا ہے

UI Automator کیا ہے؟

UI Automator Android کے فنکشنل UI ٹیسٹنگ کے لیے ایک فریم ورک ہے جو آپریٹنگ سسٹم لیول پر کام کرتا ہے۔ یہ ڈیوائس اسکرین پر کسی بھی عنصر تک رسائی کے لیے API فراہم کرتا ہے، خواہ وہ کسی بھی ایپلیکیشن کا ہو — بشمول سسٹم اسٹیٹس بار، اجازت کے ڈائیلاگ، ہوم اسکرین اور تھرڈ پارٹی ایپلیکیشنز۔ یہ اسے ایک ایپ سے باہر جانے والے منظرناموں کی جانچ کے لیے ناگزیر بناتا ہے۔

آرکیٹیکچرل طور پر، UI Automator Accessibility Service استعمال کرتا ہے — وہی سروس جو TalkBack، Switch Access اور دیگر رسائی کے اوزار استعمال کرتے ہیں۔ اس سروس کے ذریعے، فریم ورک موجودہ اسکرین کا مکمل UI اجزاء کا درخت حاصل کرتا ہے اور ان پر کارروائیاں کرنے کی اجازت دیتا ہے: ٹیپ کرنا، سوائپ کرنا، متن داخل کرنا اور لمبا دبانا۔

UI Automator پہلی بار Android 4.3 (API 18) میں ظاہر ہوا اور اس کے بعد سے کراس ایپلیکیشن ٹیسٹنگ کے لیے Google کے سرکاری آلے کے طور پر Android Testing Support Library کا حصہ ہے۔ AndroidX Test میں، یہ ایک علیحدہ آرٹیفیکٹ androidx.test.uiautomator:uiautomator ورژن 2.3.0 (2024) کے طور پر دستیاب ہے، جو API 18 سے تمام Android ورژنز کو سپورٹ کرتا ہے۔

UI Automator کیسے کام کرتا ہے

کام کرنے کا اصول: UI Automator موجودہ اسکرین کے رسائی کے درخت کو اسکین کرنے پر مبنی ہے۔ جب findObject(selector) طریقہ کار کو کال کیا جاتا ہے، فریم ورک View کے درجہ بندی کو عبور کرتا ہے، UiSelector کی شرائط سے مماثل پہلا عنصر ڈھونڈتا ہے، اور ایک UiObject لوٹاتا ہے — حقیقی View کے ساتھ تعامل کے لیے ایک پراکسی۔

UI Automator ٹیسٹ کا لائف سائیکل

ایک عام UI Automator ٹیسٹ UiDevice کی مثال حاصل کرکے شروع ہوتا ہے، جو جسمانی ڈیوائس کی نمائندگی کرتا ہے۔ UiDevice عناصر تلاش کرنے، بٹن دبانے (ہوم، بیک، ریسنٹ) کا انتظام کرنے، اسکرین گھمانے اور اسکرین شاٹ لینے کے طریقے فراہم کرتا ہے۔ UiSelector کے ذریعے عنصر تلاش کرنے کے بعد، UiObject پر کارروائیاں کی جاتی ہیں۔

بنیادی مثال

نیچے دی گئی مثال میں، ٹیسٹ سیٹنگز ایپ کھولتا ہے، متن کے ذریعے «بیٹری» آئٹم ڈھونڈتا ہے اور اسے ٹیپ کرتا ہے۔ UI Automator کو Activity لانچ کرنے کی ضرورت نہیں ہے — یہ ڈیوائس پر کسی بھی اسکرین کے ساتھ کام کرتا ہے، بشمول تھرڈ پارٹی ایپلیکیشنز۔

val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())

// سیٹنگز اسکرین کھولیں
device.pressHome()
device.wait(Until.hasObject(UiSelector().text("سیٹنگز")), 2000)

// "بیٹری" آئٹم ڈھونڈیں اور ٹیپ کریں
val batteryItem = device.findObject(
    UiSelector().text("بیٹری")
)
batteryItem.clickAndWait(Until.newWindow(), 3000)

UiDevice اور UiSelector: اہم کلاسیں

UiDevice ڈیوائس کے ساتھ تعامل کے لیے مرکزی کلاس ہے۔ یہ عناصر تلاش کرنے، ہارڈویئر بٹن دبانے (ہوم، بیک، مینو، والیوم) کی نقل کرنے، پاور کا انتظام کرنے، اسکرین شاٹ لینے اور مخصوص اسکرین کی حالتوں کے انتظار کے طریقے فراہم کرتا ہے۔ UiDevice ہر ٹیسٹ میں ایک بار بنایا جاتا ہے اور تمام کارروائیوں کے لیے دوبارہ استعمال ہوتا ہے۔

UiSelector UI عناصر تلاش کرنے کے لیے ایک فلوئنٹ API ہے۔ Espresso ViewMatchers کے برعکس، UiSelector کو تالیف کی ضرورت نہیں ہے — تلاش کی شرائط طریقوں کی ایک زنجیر کے ذریعے تشکیل پاتی ہیں: text()، className()، description()، resourceId()، index()۔ متعدد شرائط منطقی AND کے ذریعے خود بخود یکجا ہو جاتی ہیں۔

متعدد شرائط کے ساتھ تلاش کی مثال

جب اسکرین پر ایک ہی متن والے متعدد عناصر ہوتے ہیں، UiSelector معیار کو یکجا کرنے کی اجازت دیتا ہے: ID سے کنٹینر تلاش کریں، پھر اس کے اندر — متن اور کلاس سے عنصر۔ یہ مطلوبہ جزو کی منفرد شناخت کو یقینی بناتا ہے۔ childSelector طریقہ تلاش کے دائرہ کار کو ایک مخصوص کنٹینر تک محدود کرتا ہے، UI ٹری میں نیویگیشن کو تیز کرتا ہے۔

val scrollView = device.findObject(
    UiSelector().resourceId("android:id/list")
)

// فہرست کے اندر، "Wi-Fi" متن والا عنصر ڈھونڈیں
val wifiItem = scrollView.findObject(
    UiSelector().text("Wi-Fi")
wifiItem.click()

UI Automator کے ساتھ کراس ایپلیکیشن ٹیسٹنگ

کراس ایپلیکیشن (ایپلیکیشنز کے درمیان) ٹیسٹنگ وہ اہم خصوصیت ہے جس کے لیے UI Automator کا انتخاب کیا جاتا ہے۔ فریم ورک ایپلیکیشنز کے درمیان سوئچ کر سکتا ہے، براؤزر کے ذریعے OAuth لاگ ان ٹیسٹ کر سکتا ہے، سسٹم ڈائیلاگ (اجازتیں، ایپ سلیکٹر) چیک کر سکتا ہے اور سسٹم اسٹیٹس بار، نوٹیفکیشن پینل اور لاک اسکرین کے ساتھ تعامل کر سکتا ہے۔

OAuth لاگ ان کی جانچ

ایک عام کراس ایپ ٹیسٹ منظرنامہ: ایپ OAuth اجازت کے لیے براؤزر کھولتی ہے، صارف اپنا لاگ ان اور پاس ورڈ داخل کرتا ہے، اور براؤزر واپس ایپ پر ری ڈائریکٹ کرتا ہے۔ UI Automator عملوں کے درمیان سوئچ کرتا ہے، براؤزر میں ان پٹ فیلڈز ڈھونڈتا ہے، انہیں بھرتا ہے اور «سائن ان» پر ٹیپ کرتا ہے۔

// براؤزر کے ظاہر ہونے کا انتظار
device.wait(Until.hasObject(
    UiSelector().packageName("com.android.chrome")
), 5000)

// براؤزر میں ای میل ان پٹ فیلڈ کی تلاش
val emailField = device.findObject(
    UiSelector().className("android.widget.EditText").instance(0)
)
emailField.text = "user@example.com"

سسٹم ڈائیلاگ کی جانچ

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

UI Automator بمقابلہ Espresso: طریقوں کا موازنہ

انتخاب UI Automator اور Espresso کے درمیان ٹیسٹ کے منظرنامے پر منحصر ہے۔ Espresso خودکار ہم آہنگی اور کم سے کم بائلر پلیٹ کے ساتھ ایک ایپ کی جانچ کے لیے بہتر بنایا گیا ہے۔ UI Automator ان منظرناموں کے لیے موزوں ہے جہاں سسٹم، براؤزر یا متعدد ایپلیکیشنز کے ساتھ تعامل کی ضرورت ہو۔

عملی طور پر، یہ فریم ورک اکثر ایک ساتھ استعمال ہوتے ہیں: Espresso اعلی استحکام کے ساتھ مرکزی ایپ کے UI ٹیسٹ کا احاطہ کرتا ہے، جبکہ UI Automator ایپ کی حدود سے باہر جانے والے منظرناموں کے لیے استعمال ہوتا ہے — OAuth لاگ ان، سسٹم اجازتیں، Share Intent کے ساتھ کام کرنا۔ یہ مجموعہ کم سے کم ٹیسٹ کی دیکھ بھال کے اخراجات کے ساتھ زیادہ سے زیادہ UI کوریج فراہم کرتا ہے۔

Android پروجیکٹ میں UI Automator سیٹ اپ کرنا

انضمام UI Automator کا build.gradle میں انحصار شامل کرکے کیا جاتا ہے۔ فریم ورک AndroidX Test کا حصہ ہے اور مینی فیسٹ میں اضافی اجازتوں کی ضرورت نہیں ہے — آلہ کار ٹیسٹ شروع ہونے پر Accessibility Service تک رسائی خود بخود ترتیب دی جاتی ہے۔

Gradle انحصار

کم سے کم ترتیب میں uiautomator آرٹیفیکٹ اور معیاری AndroidJUnitRunner ٹیسٹ رنر شامل ہے۔ UI Automator ٹیسٹ src/androidTest ڈائریکٹری میں رکھے جاتے ہیں اور Android API 18+ چلانے والے ایمولیٹر یا جسمانی ڈیوائس پر چلائے جاتے ہیں۔

dependencies {
    androidTestImplementation("androidx.test.uiautomator:uiautomator:2.3.0")
    androidTestImplementation("androidx.test.ext:junit:1.2.1")
    androidTestImplementation("androidx.test:runner:1.6.1")
}

UiDevice اور ٹیسٹ ترتیب

UiDevice کی مثال حاصل کرنے کے لیے InstrumentationRegistry.getInstrumentation() استعمال کیا جاتا ہے۔ UiDevice کو setUp() طریقہ میں ایک بار بنایا جانا چاہیے اور ڈیوائس وسائل کو بچانے کے لیے کلاس کے تمام ٹیسٹوں میں دوبارہ استعمال کیا جانا چاہیے۔ یہ نوٹ کرنا ضروری ہے کہ UiDevice تھریڈ سیف نہیں ہے — تمام کارروائیاں ٹیسٹ طریقہ کے ایک ہی تھریڈ میں انجام دی جانی چاہئیں۔ ہر ٹیسٹ میں نیا UiDevice بنانا اوور ہیڈ کا سبب بنتا ہے اور عملدرآمد کو سست کرتا ہے۔ یہ سفارش کی جاتی ہے کہ beforeClass طریقہ میں ایک بار UiDevice بنایا جائے اور ٹیسٹ کلاس کے تمام ٹیسٹوں کے لیے دوبارہ استعمال کیا جائے۔

UI Automator میں انتظار

Espresso کے برعکس، UI Automator میں خودکار ہم آہنگی نہیں ہے۔ عناصر کے ظاہر ہونے کے انتظار کے لیے UiDevice.wait(condition, timeout) طریقہ Until آبجیکٹ کے ساتھ استعمال کیا جاتا ہے: Until.findObject(selector)، Until.hasObject(selector)، Until.gone(selector)۔ مناسب انتظار کے بغیر، ریس کنڈیشن کی وجہ سے ٹیسٹ غیر مستحکم ہو جاتے ہیں — تلاش کے وقت تک کوئی عنصر اسکرین پر ظاہر نہیں ہوا ہو سکتا۔ استحکام کے لیے کم از کم 3–5 سیکنڈ کا ٹائم آؤٹ مقرر کرنے کی سفارش کی جاتی ہے۔