Espresso — คืออะไร หลักการทำงาน และวิธีการใช้งาน

Espresso คืออะไร?

Espresso เป็นไลบรารีสำหรับเขียนการทดสอบ UI อัตโนมัติสำหรับ Android ซึ่งเป็นส่วนหนึ่งของ Google AndroidX Test โดยมี API สำหรับค้นหาองค์ประกอบ View บนหน้าจอ ดำเนินการกับองค์ประกอบเหล่านั้น (คลิก ป้อน ปัด) และตรวจสอบสถานะขององค์ประกอบ (แสดงอยู่ มีข้อความ เปิดใช้งานอยู่)

คุณสมบัติหลักของ Espresso คือ การซิงโครไนซ์อัตโนมัติ กับเธรดหลักของแอปพลิเคชัน เฟรมเวิร์กจะรอให้งานแบบอะซิงโครนัสทั้งหมด (coroutine, AsyncTask, Handler) เสร็จสมบูรณ์ก่อนดำเนินการตรวจสอบถัดไป ซึ่งช่วยลดการทดสอบที่ไม่เสถียรที่เกิดจาก race condition และทำให้การทดสอบ UI มีความเสถียรและเชื่อถือได้ — ไม่มีการทดสอบใดมี Thread.sleep() หรือลูปการรอ

Espresso ปฏิบัติตามหลักการ สุนัขสามขา — การทดสอบประกอบด้วยสามขั้นตอน: ค้นหาองค์ประกอบ (ViewMatcher), ดำเนินการ (ViewAction), ตรวจสอบผลลัพธ์ (ViewAssertion) ทั้งสามขั้นตอนเขียนเป็นลูกโซ่การเรียก: onView().perform().check() แนวคิดนี้ทำให้การทดสอบคาดการณ์ได้และอ่านง่าย — การทดสอบแต่ละครั้งอธิบายอย่างชัดเจนว่าค้นหาอะไร ทำอะไร และตรวจสอบอะไร

Espresso ทำงานอย่างไร

สถาปัตยกรรม ของ Espresso ขึ้นอยู่กับสามคอมโพเนนต์: Espresso (จุดเริ่มต้น — เมธอดสแตติก onView และ onData), ViewMatchers (การค้นหาองค์ประกอบ), ViewActions(การดำเนินการ) และ ViewAssertions(การตรวจสอบ) ภายในเฟรมเวิร์กใช้ Idling Resource เพื่อซิงโครไนซ์กับเธรด UI

การทดสอบ 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 ช่วยให้ทดสอบวงจรชีวิตของ Activity นอกเหนือจากการทดสอบ UI บริสุทธิ์ ตัวอย่างเช่น คุณสามารถตรวจสอบว่าข้อมูลถูกเก็บรักษาไว้เมื่อหมุนหน้าจอ (การสร้าง Activity ใหม่) และถูกกู้คืนหลังจากการทำลาย

ViewMatchers: การค้นหาองค์ประกอบ UI

ViewMatchers คือชุดของเมธอดจากคลาส Espresso.onView ที่ช่วยให้ค้นหา Views บนหน้าจอตามเกณฑ์ต่างๆ: ID ทรัพยากร (R.id), ข้อความ, คำแนะนำ, องค์ประกอบหลัก และลำดับชั้น หาก matcher หนึ่งไม่ให้ผลลัพธ์ที่ไม่ซ้ำกัน สามารถรวม matchers เข้าด้วยกันโดยใช้ allOf()

การรวม Matchers

หากมีองค์ประกอบที่เหมือนกันหลายรายการบนหน้าจอ (เช่น สอง TextView ที่มีข้อความต่างกัน) การรวม matchers โดยใช้ 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) จะใช้เมธอด onData() แทน onView โดยทำงานกับข้อมูลอะแดปเตอร์มากกว่า Views — ค้นหาองค์ประกอบตามเนื้อหาโมเดลและส่งคืน View ที่เกี่ยวข้องสำหรับการดำเนินการเพิ่มเติม onData ใช้ hamcrest matchers เพื่อค้นหาองค์ประกอบตามฟิลด์ข้อมูลโมเดล

ViewAssertions: การตรวจสอบสถานะ

ViewAssertions ตรวจสอบว่า View อยู่ในสถานะที่ระบุ เมธอดพื้นฐาน — matches(matcher) — ตรวจสอบว่าองค์ประกอบตรงกับ matcher ที่กำหนด นอกจากนี้ Espresso ยังมี doesNotExist() (องค์ประกอบไม่มีอยู่) และ selectedDescendantsMatch() (การตรวจสอบองค์ประกอบที่ซ้อนกัน)

การตรวจสอบทั่วไป

การตรวจสอบที่พบบ่อยที่สุดในการทดสอบ UI: องค์ประกอบแสดงอยู่ (isDisplayed), องค์ประกอบมีข้อความที่ระบุ (withText), องค์ประกอบเปิดใช้งานอยู่ (isEnabled), องค์ประกอบไม่ได้ถูกเลือก (isNotChecked) แต่ละการตรวจสอบจะโยนข้อยกเว้นโดยละเอียดเมื่อล้มเหลว — รวมถึงลำดับชั้น View บนหน้าจอ ซึ่งช่วยให้การดีบักง่ายขึ้น: ข้อความแสดงข้อผิดพลาดแสดงองค์ประกอบที่อยู่บนหน้าจอจริงในขณะที่ตรวจสอบ

ViewAssertions แบบกำหนดเอง

หากการตรวจสอบมาตรฐานไม่เพียงพอ สามารถสร้างแบบกำหนดเองผ่านอินเทอร์เฟซ ViewAssertion assertion แบบกำหนดเองจะได้รับ View และสามารถตรวจสอบสถานะโดยทางโปรแกรม — ตัวอย่างเช่น สีข้อความ, ระยะห่างภายใน หรือสถานะของคอมโพเนนต์ที่กำหนดเองที่ไม่ได้เปิดเผยผ่าน matchers มาตรฐาน

// ตรวจสอบ: 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 และ coroutine (ผ่าน coroutinesIdlingResource) หากแอปพลิเคชันทำงานเบื้องหลังผ่านเธรดที่กำหนดเองหรือบริการ callback จำเป็นต้องลงทะเบียน Idling Resource แบบกำหนดเอง

ตัวอย่างกับ Coroutine

ตั้งแต่ AndroidX Test 1.4.0 เป็นต้นไป Espresso รองรับ coroutine ผ่าน CoroutinesIdlingResource การทดสอบจะรอโดยอัตโนมัติให้ coroutine ที่เริ่มต้นทั้งหมดเสร็จสมบูรณ์ก่อนดำเนินการตรวจสอบ UI สำหรับสถานการณ์ที่ซับซ้อนมากขึ้น จะใช้ CountingIdlingResource — ตัวนับที่เพิ่มขึ้นเมื่อเริ่มงานและลดลงเมื่อเสร็จสมบูรณ์

// ลงทะเบียน IdlingResource สำหรับ OkHttp
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
    }
}

การตั้งค่า Espresso ในโปรเจกต์ Android

การเชื่อมต่อ Espresso ในโปรเจกต์ Android ทำได้โดยเพิ่ม dependencies ใน build.gradle ระดับโมดูล Espresso เป็นส่วนหนึ่งของ AndroidX Test ดังนั้นเพียงระบุ dependencies สำหรับแกน Espresso, ส่วนขยาย และการรวม JUnit การทดสอบจะถูกวางในไดเรกทอรี src/androidTest และทำงานบนอุปกรณ์จริงหรืออีมูเลเตอร์ผ่าน AndroidJUnitRunner

การกำหนดค่า Gradle

ชุด dependencies ขั้นต่ำประกอบด้วย espresso-core (แกน), espresso-contrib (matchers เพิ่มเติมสำหรับ RecyclerView, Drawer, Picker) และ runner (ตัวเรียกใช้การทดสอบ AndroidX) การทดสอบทั้งหมดทำงานบนอีมูเลเตอร์หรืออุปกรณ์จริงผ่าน Android Test Orchestrator

// build.gradle.kts (dependencies 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 — การกระจายการทดสอบระหว่างอีมูเลเตอร์หลายตัว