अपने टेस्ट सिंक करना

Compose टेस्ट, डिफ़ॉल्ट रूप से आपके यूज़र इंटरफ़ेस (यूआई) के साथ सिंक होते हैं. ComposeTestRule का इस्तेमाल करके किसी दावे या कार्रवाई को कॉल करने पर, टेस्ट को पहले से ही सिंक कर दिया जाता है. यह तब तक इंतज़ार करता है, जब तक यूज़र इंटरफ़ेस (यूआई) ट्री निष्क्रिय न हो जाए.

आम तौर पर, आपको कुछ भी नहीं करना होता. हालांकि, कुछ खास मामलों के बारे में आपको पता होना चाहिए.

जब कोई टेस्ट सिंक किया जाता है, तो वर्चुअल क्लॉक का इस्तेमाल करके आपके Compose ऐप्लिकेशन को आगे बढ़ाया जाता है. इसका मतलब है कि कंपोज़ टेस्ट रीयल टाइम में नहीं चलते हैं, इसलिए वे जल्द से जल्द पास हो सकते हैं.

हालांकि, अगर टेस्ट को सिंक करने के लिए इस्तेमाल किए जाने वाले तरीकों का इस्तेमाल नहीं किया जाता है, तो कोई रीकंपोज़िशन नहीं होगा और यूज़र इंटरफ़ेस (यूआई) रुका हुआ दिखेगा.

@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()
}

ध्यान दें कि यह ज़रूरी शर्त सिर्फ़ कंपोज़ करने की सुविधा के लिए है. यह ऐप्लिकेशन के बाकी हिस्सों पर लागू नहीं होती.

अपने-आप सिंक होने की सुविधा बंद करना

जब ComposeTestRule के ज़रिए किसी दावे या कार्रवाई को कॉल किया जाता है, तो आपका टेस्ट Compose UI के साथ सिंक हो जाता है. जैसे, assertExists(). कुछ मामलों में, आपको इस सिंक्रनाइज़ेशन को रोकना पड़ सकता है और घड़ी को खुद कंट्रोल करना पड़ सकता है. उदाहरण के लिए, यूज़र इंटरफ़ेस (यूआई) के व्यस्त होने पर भी, ऐनिमेशन के सटीक स्क्रीनशॉट लेने के लिए समय को कंट्रोल किया जा सकता है. अपने-आप सिंक होने की सुविधा बंद करने के लिए, प्रॉपर्टी में autoAdvance को mainClock पर false सेट करें:

composeTestRule.mainClock.autoAdvance = false

आम तौर पर, आपको समय खुद ही आगे बढ़ाना होगा. advanceTimeByFrame() की मदद से, एक फ़्रेम आगे बढ़ा जा सकता है. इसके अलावा, advanceTimeBy() की मदद से, वीडियो को किसी खास अवधि के लिए आगे बढ़ाया जा सकता है:

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

आइडल रिसॉर्स

Compose, टेस्ट और यूज़र इंटरफ़ेस (यूआई) को सिंक कर सकता है, ताकि हर कार्रवाई और पुष्टि को आइडल स्टेट में किया जा सके. साथ ही, ज़रूरत के हिसाब से घड़ी को रोका या आगे बढ़ाया जा सके. हालांकि, कुछ एसिंक्रोनस कार्रवाइयां ऐसी होती हैं जिनके नतीजे, यूज़र इंटरफ़ेस (यूआई) की स्थिति पर असर डालते हैं. इन्हें बैकग्राउंड में चलाया जा सकता है. इस दौरान, टेस्ट को इनके बारे में पता नहीं चलता.

अपने टेस्ट में इन आइडलिंग रिसॉर्स को बनाएं और रजिस्टर करें, ताकि यह तय करते समय इनका ध्यान रखा जा सके कि टेस्ट किया जा रहा ऐप्लिकेशन व्यस्त है या कुछ समय से इस्तेमाल में नहीं है. जब तक आपको अतिरिक्त आइडलिंग संसाधनों को रजिस्टर करने की ज़रूरत न हो, तब तक आपको कोई कार्रवाई करने की ज़रूरत नहीं है. उदाहरण के लिए, अगर आपको कोई ऐसा बैकग्राउंड जॉब चलाना है जो Espresso या Compose के साथ सिंक नहीं किया गया है.

यह एपीआई, Espresso के आइडलिंग रिसॉर्स से काफ़ी मिलता-जुलता है. इसका इस्तेमाल यह बताने के लिए किया जाता है कि टेस्ट किया जा रहा विषय, फ़िलहाल कुछ समय से इस्तेमाल में नहीं है या काम कर रहा है. IdlingResource को लागू करने के लिए, Compose test rule का इस्तेमाल करें.

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

मैन्युअल तरीके से सिंक्रनाइज़ करना

कुछ मामलों में, आपको Compose UI को अपने टेस्ट या उस ऐप्लिकेशन के अन्य हिस्सों के साथ सिंक करना होगा जिसकी जांच की जा रही है.

waitForIdle() फ़ंक्शन, Compose के आइडल होने का इंतज़ार करता है. हालांकि, यह फ़ंक्शन 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.

ध्यान दें कि दोनों ही मामलों में, waitForIdle() को ड्रॉ और लेआउट पास के पूरा होने का इंतज़ार करना पड़ता है.

इसके अलावा, advanceTimeUntil() की मदद से, किसी शर्त के पूरा होने तक घड़ी को आगे बढ़ाया जा सकता है.

composeTestRule.mainClock.advanceTimeUntil(timeoutMs) { condition }

ध्यान दें कि दी गई शर्त में, उस स्थिति की जांच की जानी चाहिए जिस पर इस क्लॉक का असर पड़ सकता है. यह सिर्फ़ कंपोज़ स्टेट के साथ काम करती है.

ऐनिमेशन टेस्ट को ऑप्टिमाइज़ करना

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.

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

मुख्य थ्रेड सिंक्रनाइज़ेशन

Compose टेस्टिंग में अब मुख्य थ्रेड सिंक्रनाइज़ेशन की सुविधा उपलब्ध है. इससे आपको मुख्य थ्रेड से सीधे तौर पर waitForIdle कॉल करने की अनुमति मिलती है. साथ ही, Compose यूआई कार्रवाइयां और दावे भी किए जा सकते हैं.

इससे पहले, Compose टेस्टिंग में दो थ्रेड मॉडल का सख्ती से पालन किया जाता था: टेस्ट का एक्ज़ीक्यूशन, बैकग्राउंड टेस्ट थ्रेड पर होता था. वहीं, यूज़र इंटरफ़ेस (यूआई) अपडेट, मुख्य थ्रेड पर होते थे. मुख्य थ्रेड से waitForIdle या runOnIdle जैसे सिंक्रनाइज़ेशन के तरीकों को कॉल करने पर, IllegalStateException गड़बड़ी दिखेगी. उदाहरण के लिए, runOnUiThread ब्लॉक के अंदर. ऐसा इसलिए होगा, क्योंकि फ़्रेमवर्क ने थ्रेड की जांच को सख्ती से लागू किया है, ताकि मुख्य थ्रेड को सिंक्रनाइज़ होने से रोका जा सके.

मुख्य थ्रेड सिंक्रनाइज़ेशन चालू होने पर, Compose टेस्ट फ़्रेमवर्क अब घड़ी को आगे बढ़ा सकता है और लंबित काम को प्रोसेस कर सकता है. ऐसा तब भी किया जा सकता है, जब मुख्य थ्रेड पर कॉल ब्लॉक किए जा रहे हों.

मुख्य थ्रेड के सिंक्रनाइज़ेशन का इस्तेमाल कब करना चाहिए

प्योर कंपोज़ टेस्ट के लिए, बैकग्राउंड थ्रेड पर टेस्ट करने की सुविधा अब भी उपलब्ध है. हालांकि, कुछ खास मामलों में मुख्य थ्रेड सिंक्रनाइज़ेशन का इस्तेमाल करना ज़्यादा फ़ायदेमंद होता है:

• कॉम्प्लेक्स व्यू के साथ इंटरऑपरेबिलिटी: Compose और लेगसी Android व्यू, दोनों को शामिल करने वाले हाइब्रिड यूज़र इंटरफ़ेस (यूआई) की टेस्टिंग करते समय, व्यू में बदलाव करने के लिए अक्सर मुख्य थ्रेड पर चलना ज़रूरी होता है. अब थ्रेड के कॉन्टेक्स्ट को लगातार स्विच किए बिना, व्यू के साथ इंटरैक्ट किया जा सकता है और कंपोज़ नोड पर क्रम से पुष्टि की जा सकती है.
• सिंक्रोनस स्टेट म्यूटेशन: अगर आपका आर्किटेक्चर, मुख्य थ्रेड से जुड़े स्टेट होल्डर पर निर्भर करता है, तो अब स्टेट में बदलाव किया जा सकता है. साथ ही, मुख्य थ्रेड छोड़े बिना, Compose UI के सेटल होने का इंतज़ार किया जा सकता है.
• कस्टम टेस्ट रनर: अगर कस्टम टेस्टिंग इंफ़्रास्ट्रक्चर बनाया जा रहा है या ऐसे एनवायरमेंट का इस्तेमाल किया जा रहा है जहां टेस्ट रनर, मुख्य थ्रेड पर अपने-आप काम करता है, तो Compose टेस्ट अब बैकग्राउंड-थ्रेड डेलिगेशन की ज़रूरत के बिना आसानी से काम करते हैं.

उदाहरण

पहले, मुख्य थ्रेड पर सिंक्रनाइज़ेशन की अनुमति नहीं थी. इसलिए, डेवलपर को बैकग्राउंड टेस्ट रनर थ्रेड और यूज़र इंटरफ़ेस (यूआई) थ्रेड के बीच बार-बार स्विच करना पड़ता था. इससे टेस्ट अलग-अलग हो जाते थे:

@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

मुख्य थ्रेड सिंक्रनाइज़ेशन चालू होने पर, Compose और View के लिए दावे, एक ही ब्लॉक में लागू किए जा सकते हैं:

@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

शर्तें पूरी होने का इंतज़ार करें

ऐसी कोई भी शर्त जो बाहरी काम पर निर्भर करती है, जैसे कि डेटा लोड करना या Android का मेज़र या ड्रॉ (यानी, Compose के बाहर मेज़र या ड्रॉ करना), को waitUntil() जैसे ज़्यादा सामान्य कॉन्सेप्ट का इस्तेमाल करना चाहिए:

composeTestRule.waitUntil(timeoutMs) { condition }

इनमें से किसी भी waitUntil हेल्पर का इस्तेमाल भी किया जा सकता है:

composeTestRule.waitUntilAtLeastOneExists(matcher, timeoutMs)

composeTestRule.waitUntilDoesNotExist(matcher, timeoutMs)

composeTestRule.waitUntilExactlyOneExists(matcher, timeoutMs)

composeTestRule.waitUntilNodeCount(matcher, count, timeoutMs)

अतिरिक्त संसाधन

• Android पर ऐप्लिकेशन की टेस्टिंग: Android टेस्टिंग के मुख्य लैंडिंग पेज पर, टेस्टिंग की बुनियादी बातों और तकनीकों के बारे में ज़्यादा जानकारी मिलती है.
• टेस्टिंग की बुनियादी बातें: Android ऐप्लिकेशन की टेस्टिंग से जुड़े मुख्य कॉन्सेप्ट के बारे में ज़्यादा जानें.
• लोकल टेस्ट: कुछ टेस्ट, अपने वर्कस्टेशन पर स्थानीय तौर पर किए जा सकते हैं.
• इंस्ट्रुमेंट किए गए टेस्ट: इंस्ट्रूमेंट किए गए टेस्ट भी चलाएं. इसका मतलब है कि ऐसे टेस्ट जो सीधे तौर पर डिवाइस पर चलते हैं.
• लगातार इंटिग्रेशन करना: लगातार इंटिग्रेशन करने की सुविधा की मदद से, अपनी जांचों को डिप्लॉयमेंट पाइपलाइन में इंटिग्रेट किया जा सकता है.
• अलग-अलग स्क्रीन साइज़ के लिए टेस्ट करें: उपयोगकर्ताओं के लिए कई तरह के डिवाइस उपलब्ध हैं. इसलिए, आपको अलग-अलग स्क्रीन साइज़ के लिए टेस्ट करना चाहिए.
• Espresso: इसे व्यू पर आधारित यूज़र इंटरफ़ेस (यूआई) के लिए बनाया गया है. हालांकि, Espresso की जानकारी, Compose की टेस्टिंग के कुछ पहलुओं के लिए अब भी मददगार हो सकती है.