Menyinkronkan pengujian Anda

Uji Compose disinkronkan secara default dengan UI Anda. Saat Anda memanggil pernyataan atau tindakan dengan ComposeTestRule, pengujian akan disinkronkan terlebih dahulu, menunggu hingga pohon UI tidak ada aktivitas.

Biasanya, Anda tidak perlu melakukan tindakan apa pun. Namun, ada beberapa kasus ekstrem yang harus Anda ketahui.

Saat pengujian disinkronkan, aplikasi Compose dimajukan menggunakan jam virtual. Ini berarti pengujian Compose tidak berjalan secara real time, sehingga dapat lulus secepat mungkin.

Namun, jika Anda tidak menggunakan metode yang menyinkronkan pengujian, tidak ada rekomposisi yang akan terjadi dan UI akan dijeda.

@Test
fun counterTest() {
    val myCounter = mutableStateOf(0) // State that can cause recompositions.
    var lastSeenValue = 0 // Used to track recompositions.
    composeTestRule.setContent {
        Text(myCounter.value.toString())
        lastSeenValue = myCounter.value
    }
    myCounter.value = 1 // The state changes, but there is no recomposition.

    // Fails because nothing triggered a recomposition.
    assertTrue(lastSeenValue == 1)

    // Passes because the assertion triggers recomposition.
    composeTestRule.onNodeWithText("1").assertExists()
}

Perhatikan bahwa persyaratan ini hanya berlaku untuk hierarki Compose, dan tidak untuk aplikasi lainnya.

Menonaktifkan sinkronisasi otomatis

Saat Anda memanggil pernyataan atau tindakan melalui ComposeTestRule seperti assertExists(), pengujian Anda akan disinkronkan dengan Compose UI. Dalam beberapa kasus, Anda mungkin ingin menghentikan sinkronisasi ini dan mengontrol sendiri jamnya. Misalnya, Anda dapat mengontrol waktu untuk mengambil screenshot animasi yang akurat pada suatu titik dan UI akan tetap sibuk. Untuk menonaktifkan sinkronisasi otomatis, setel properti autoAdvance dalam mainClock ke false:

composeTestRule.mainClock.autoAdvance = false

Biasanya Anda kemudian akan memajukan waktu sendiri. Anda dapat memajukan satu frame dengan advanceTimeByFrame() atau berdasarkan durasi tertentu dengan advanceTimeBy():

composeTestRule.mainClock.advanceTimeByFrame()
composeTestRule.mainClock.advanceTimeBy(milliseconds)

Catatan: MainTestClock bertanggung jawab untuk mendorong semua rekomposisi, animasi, dan gestur. API tidak mengontrol pengukuran dan proses gambar Android passes.

Resource nonaktif

Compose dapat menyinkronkan pengujian dan UI sehingga setiap tindakan dan pernyataan dilakukan dalam status tidak ada aktivitas, menunggu, atau mendukung jam sesuai kebutuhan. Namun, beberapa operasi asinkron yang hasilnya memengaruhi status UI dapat dijalankan di latar belakang saat pengujian tidak menyadarinya.

Buat dan daftarkan resource nonaktif ini dalam pengujian sehingga resource tersebut diperhitungkan saat memutuskan apakah aplikasi yang sedang diuji sibuk atau tidak. Anda tidak perlu melakukan tindakan apa pun kecuali jika perlu mendaftarkan resource nonaktif tambahan, misalnya, jika Anda menjalankan tugas latar belakang yang tidak disinkronkan dengan Espresso atau Compose.

API ini sangat mirip dengan Resource Nonaktif Espresso untuk menunjukkan apakah subjek dalam pengujian sedang tidak ada aktivitas atau sibuk. Gunakan aturan pengujian Compose untuk mendaftarkan penerapan IdlingResource.

composeTestRule.registerIdlingResource(idlingResource)
composeTestRule.unregisterIdlingResource(idlingResource)

Sinkronisasi manual

Dalam kasus tertentu, Anda harus menyinkronkan Compose UI dengan bagian lain dari pengujian atau aplikasi yang sedang Anda uji.

Fungsi waitForIdle() menunggu Compose menjadi tidak ada aktivitas, tetapi fungsi ini bergantung pada properti autoAdvance:

composeTestRule.mainClock.autoAdvance = true // Default
composeTestRule.waitForIdle() // Advances the clock until Compose is idle.

composeTestRule.mainClock.autoAdvance = false
composeTestRule.waitForIdle() // Only waits for idling resources to become idle.

Perhatikan bahwa dalam kedua kasus tersebut, waitForIdle() juga menunggu proses gambar dan tata letak yang tertunda.

Selain itu, Anda dapat meningkatkan waktu hingga kondisi tertentu terpenuhi dengan advanceTimeUntil().

composeTestRule.mainClock.advanceTimeUntil(timeoutMs) { condition }

Perhatikan bahwa ketentuan yang diberikan harus memeriksa status yang dapat dipengaruhi oleh jam ini (hanya berfungsi dengan status Compose).

Mengoptimalkan pengujian animasi

Note: The runWithoutImplicitWait API is included in androidx.compose.ui:ui-test-junit4:1.12.0-alpha03+ and androidx.compose.ui:ui-test:1.12.0-alpha03+.

When testing high-fidelity animations, you often need to disable auto-advance and manually step through frames to assert intermediate UI states. For these specific frame-by-frame loops, use the runWithoutImplicitWait method to execute your assertions. Standard node queries (like onNodeWithTag or fetchSemanticsNode) trigger implicit synchronizations that are redundant when you are manually controlling the clock, so bypassing them significantly speeds up your test runtimes.

Note: This API is a specialized performance optimization designed strictly for manual frame-by-frame animation testing. It is not intended for general-purpose UI tests and won't provide meaningful performance improvements outside of manual clock advancement loops.

Usage guidelines

• Manual clock management: Use this API when mainClock.autoAdvance is set to false and the UI is in a known, stable state for the current frame.
• UI thread execution: To ensure the stability of the UI tree, call runWithoutImplicitWait on the UI thread, such as with runOnUiThread. Running it off the UI thread exposes your test to race conditions and stale state reads.
• Read-only assertions: The block should strictly contain read-only assertions. Any actions that mutate state should be performed outside of this block.

Example

@Test
fun runWithoutImplicitWaitSample() = runComposeUiTest {
    setContent { MainScreen() }
    mainClock.autoAdvance = false

    // Trigger an animation
    onNodeWithText("Start Animation").performClick()

    // Step through the animation frame-by-frame
    while (hasPendingWork()) {
        mainClock.advanceTimeByFrame()
        waitForIdle()
        runOnUiThread {
            // Suppress implicit synchronization inside this block to avoid redundant
            // waits on each node query, making the frame assertions execute much faster.
            runWithoutImplicitWait {
                val box1 = onNodeWithTag("Box1").fetchSemanticsNode()
                val box2 = onNodeWithTag("Box2").fetchSemanticsNode()
                val box3 = onNodeWithTag("Box3").fetchSemanticsNode()

                // Assert the exact intermediate state of all three properties for this frame
                assert(box1.boundsInRoot.right <= box2.boundsInRoot.left)
                assert(box2.boundsInRoot.right <= box3.boundsInRoot.left)
            }
        }
    }
}
TestSyncSnippets.kt

Sinkronisasi thread utama

Catatan: Perubahan untuk mendukung sinkronisasi thread utama disertakan dalam androidx.compose.ui:ui-test-junit4:1.13.0-alpha01+ dan androidx.compose.ui:ui-test:1.13.0-alpha01+.

Pengujian Compose kini mendukung sinkronisasi thread utama, sehingga Anda dapat memanggil waitForIdle dengan aman—dan dengan ekstensi, tindakan dan pernyataan Compose UI—langsung dari thread utama.

Sebelumnya, pengujian Compose secara ketat menerapkan model dua thread: eksekusi pengujian terjadi pada thread pengujian latar belakang, sedangkan update UI terjadi pada thread utama. Memanggil metode sinkronisasi seperti waitForIdle atau runOnIdle dari thread utama (misalnya, di dalam blok runOnUiThread) akan menampilkan IllegalStateException karena framework menerapkan pemeriksaan thread yang ketat untuk mencegah sinkronisasi thread utama.

Dengan sinkronisasi thread utama yang diaktifkan, framework pengujian Compose kini dapat memajukan jam dan memproses pekerjaan yang tertunda meskipun panggilan pemblokiran dilakukan di thread utama.

Kapan harus menggunakan sinkronisasi thread utama

Meskipun pengujian di thread latar belakang tetap menjadi standar untuk pengujian Compose murni, sinkronisasi thread utama sangat menguntungkan dalam beberapa skenario tertentu:

• Interoperabilitas View yang kompleks: Saat menguji UI hybrid yang berisi Compose dan View Android lama, memanipulasi View sering kali memerlukan menjalankan di thread utama. Anda kini dapat berinteraksi dengan View dan membuat pernyataan pada node Compose secara berurutan tanpa terus-menerus beralih konteks thread.
• Mutasi status sinkron: Jika arsitektur Anda mengandalkan pemegang status yang terikat secara ketat dengan thread utama, Anda kini dapat memutasi status dan langsung menunggu Compose UI diselesaikan tanpa meninggalkan thread utama.
• Runner pengujian kustom: Jika Anda membuat infrastruktur pengujian kustom atau menggunakan lingkungan tempat runner pengujian secara inheren dieksekusi di thread utama, pengujian Compose kini dieksekusi dengan bersih tanpa memerlukan delegasi thread latar belakang.

Catatan: Untuk pengujian standar yang hanya menggunakan Compose, Anda tidak perlu mengubah kode pengujian yang ada. Eksekusi thread latar belakang default tetap didukung sepenuhnya dan berperforma.

Contoh

Secara historis, karena sinkronisasi dilarang secara ketat di thread utama, developer harus bolak-balik antara thread runner pengujian latar belakang dan thread UI, sehingga pengujian menjadi terputus-putus:

@Test
fun testBidirectionalInteropUIUpdates_old() {
    val scenario = launchFragmentInContainer<InteropFragment>()
    composeTestRule.waitForIdle()
    scenario.onFragment { fragment ->
        fragment.legacyButton.performClick()
    }
    // Jump to Test Thread to verify state settles inside compose
    composeTestRule.waitForIdle()
    composeTestRule.onNodeWithText("Legacy Clicks: 1").assertIsDisplayed()
    composeTestRule.onNodeWithText("Increment Legacy TextView").performClick()
    composeTestRule.waitForIdle()
    // Jump back to Main Thread to verify target view state settles
    scenario.onFragment { fragment ->
        assert(fragment.legacyTextView.text.toString() == "Compose Clicks: 1")
    }
}
TestSyncSnippets.kt

Dengan sinkronisasi thread utama yang diaktifkan, pernyataan untuk hierarki Compose dan View dapat dieksekusi dalam blok yang sama:

@Test
fun testBidirectionalInteropUIUpdates_new() {
    val scenario = launchFragmentInContainer<InteropFragment>()
    composeTestRule.waitForIdle()
    scenario.onFragment { fragment ->
        fragment.legacyButton.performClick()
        composeTestRule.waitForIdle()
        composeTestRule.onNodeWithText("Legacy Clicks: 1").assertIsDisplayed()
        composeTestRule.onNodeWithText("Increment Legacy TextView").performClick()
        composeTestRule.waitForIdle()
        assert(fragment.legacyTextView.text.toString() == "Compose Clicks: 1")
    }
}
TestSyncSnippets.kt

Menunggu kondisi

Setiap kondisi yang bergantung pada pekerjaan eksternal, seperti pemuatan data atau ukuran atau gambar Android (yaitu, mengukur atau menggambar eksternal untuk Compose), harus menggunakan konsep yang lebih umum seperti waitUntil():

composeTestRule.waitUntil(timeoutMs) { condition }

Anda juga dapat menggunakan salah satu helper waitUntil:

composeTestRule.waitUntilAtLeastOneExists(matcher, timeoutMs)

composeTestRule.waitUntilDoesNotExist(matcher, timeoutMs)

composeTestRule.waitUntilExactlyOneExists(matcher, timeoutMs)

composeTestRule.waitUntilNodeCount(matcher, count, timeoutMs)

Peringatan: Dalam beberapa kasus, menggunakan mekanisme dalam pengujian seperti CountDownLatch eksternal, bukan API waitUntil, dapat berperilaku tidak terduga, karena jam pengujian tidak akan berfungsi tingkat lanjut.

Referensi Tambahan

• Menguji aplikasi di Android: Halaman landing pengujian Android utama memberikan tampilan yang lebih luas tentang dasar-dasar dan teknik pengujian.
• Dasar-dasar pengujian: Pelajari lebih lanjut konsep inti di balik pengujian aplikasi Android.
• Pengujian lokal: Anda dapat menjalankan beberapa pengujian secara lokal, di workstation Anda sendiri.
• Pengujian berinstrumen: Sebaiknya jalankan juga pengujian berinstrumen. Yaitu, pengujian yang berjalan langsung di perangkat.
• Integrasi berkelanjutan: Integrasi berkelanjutan memungkinkan Anda mengintegrasikan pengujian ke dalam pipeline deployment.
• Menguji berbagai ukuran layar: Dengan banyaknya perangkat yang tersedia bagi pengguna, Anda harus menguji berbagai ukuran layar.
• Espresso: Meskipun ditujukan untuk UI berbasis Tampilan, pengetahuan Espresso masih dapat membantu untuk beberapa aspek pengujian Compose.