सामान्य पैटर्न

आपके पास, Compose ऐप्लिकेशन को अच्छी तरह से जांचने के लिए, जाने-माने तरीकों और पैटर्न का इस्तेमाल करने का विकल्प होता है.

अलग से जांच करना

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

इसका मतलब यह नहीं है कि आपको सिर्फ़ यूनिट यूज़र इंटरफ़ेस (यूआई) टेस्ट बनाने चाहिए. यूज़र इंटरफ़ेस (यूआई) के बड़े हिस्सों की जांच करने वाले यूआई टेस्ट भी बहुत ज़रूरी होते हैं.

अपना कॉन्टेंट सेट करने के बाद, गतिविधि और संसाधनों को ऐक्सेस करना

कई बार आपको composeTestRule.setContent का इस्तेमाल करके, टेस्ट किए जा रहे कॉन्टेंट को सेट करना होता है. साथ ही, आपको गतिविधि के संसाधनों को भी ऐक्सेस करना होता है. उदाहरण के लिए, यह पुष्टि करने के लिए कि दिखाया गया टेक्स्ट, स्ट्रिंग संसाधन से मेल खाता है. हालांकि, अगर गतिविधि पहले से ही setContent को कॉल करती है, तो createAndroidComposeRule() का इस्तेमाल करके बनाए गए नियम पर setContent को कॉल नहीं किया जा सकता.

इसके लिए, आम तौर पर ComponentActivity जैसी खाली गतिविधि का इस्तेमाल करके, AndroidComposeTestRule बनाया जाता है.

class MyComposeTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<ComponentActivity>()

    @Test
    fun myTest() {
        // Start the app
        composeTestRule.setContent {
            MyAppTheme {
                MainScreen(uiState = exampleUiState, /*...*/)
            }
        }
        val continueLabel = composeTestRule.activity.getString(R.string.next)
        composeTestRule.onNodeWithText(continueLabel).performClick()
    }
}

ध्यान दें कि ComponentActivity को आपके ऐप्लिकेशन की AndroidManifest.xml फ़ाइल में जोड़ना होगा. इसे चालू करने के लिए, अपने मॉड्यूल में यह डिपेंडेंसी जोड़ें:

debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

कस्टम सिमैंटिक्स प्रॉपर्टी

टेस्ट में जानकारी दिखाने के लिए, कस्टम सिमैंटिक्स प्रॉपर्टी बनाई जा सकती हैं. इसके लिए, एक नया SemanticsPropertyKey तय करें और उसे SemanticsPropertyReceiver का इस्तेमाल करके उपलब्ध कराएं.

// Creates a semantics property of type Long.
val PickedDateKey = SemanticsPropertyKey<Long>("PickedDate")
var SemanticsPropertyReceiver.pickedDate by PickedDateKey

अब उस प्रॉपर्टी का इस्तेमाल semantics मॉडिफ़ायर में करें:

val datePickerValue by remember { mutableStateOf(0L) }
MyCustomDatePicker(
    modifier = Modifier.semantics { pickedDate = datePickerValue }
)

जांचों में, प्रॉपर्टी की वैल्यू की पुष्टि करने के लिए SemanticsMatcher.expectValue का इस्तेमाल करें:

composeTestRule
    .onNode(SemanticsMatcher.expectValue(PickedDateKey, 1445378400)) // 2015-10-21
    .assertExists()

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

स्टेट को वापस लाने की पुष्टि करना

पुष्टि करें कि गतिविधि या प्रोसेस को फिर से बनाए जाने पर, आपके कंपोज़ एलिमेंट की स्थिति सही तरीके से वापस आ गई हो. StateRestorationTester क्लास की मदद से, गतिविधि को फिर से बनाने पर भरोसा किए बिना ऐसी जांच करें.

इस क्लास की मदद से, कंपोज़ेबल को फिर से बनाने का सिम्युलेशन किया जा सकता है. यह खास तौर पर, rememberSaveable को लागू करने की पुष्टि करने के लिए फ़ायदेमंद है.

class MyStateRestorationTests {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun onRecreation_stateIsRestored() {
        val restorationTester = StateRestorationTester(composeTestRule)

        restorationTester.setContent { MainScreen() }

        // TODO: Run actions that modify the state

        // Trigger a recreation
        restorationTester.emulateSavedInstanceStateRestore()

        // TODO: Verify that state has been correctly restored.
    }
}

अलग-अलग डिवाइस कॉन्फ़िगरेशन की जांच करना

Android ऐप्लिकेशन को कई तरह की बदलती स्थितियों के हिसाब से काम करना होता है. जैसे, विंडो के साइज़, स्थान-भाषा, फ़ॉन्ट के साइज़, गहरे और हल्के रंग वाली थीम वगैरह. इनमें से ज़्यादातर शर्तें, डिवाइस-लेवल की वैल्यू से तय होती हैं. इन्हें उपयोगकर्ता कंट्रोल करता है और ये मौजूदा Configuration इंस्टेंस के साथ दिखती हैं. किसी टेस्ट में अलग-अलग कॉन्फ़िगरेशन की जांच करना मुश्किल होता है, क्योंकि टेस्ट को डिवाइस-लेवल की प्रॉपर्टी कॉन्फ़िगर करनी होती हैं.

DeviceConfigurationOverride सिर्फ़ टेस्टिंग के लिए उपलब्ध एपीआई है. इसकी मदद से, टेस्ट किए जा रहे @Composable कॉन्टेंट के लिए, स्थानीय भाषा में अलग-अलग डिवाइस कॉन्फ़िगरेशन का सिम्युलेशन किया जा सकता है.

DeviceConfigurationOverride के कंपैनियन ऑब्जेक्ट में ये एक्सटेंशन फ़ंक्शन होते हैं. ये डिवाइस-लेवल के कॉन्फ़िगरेशन प्रॉपर्टी को बदल देते हैं:

• DeviceConfigurationOverride.DarkMode(): यह सिस्टम की सेटिंग को बदलकर, गहरे रंग वाली थीम या हल्के रंग वाली थीम सेट करता है.
• DeviceConfigurationOverride.FontScale(): यह सिस्टम फ़ॉन्ट के साइज़ को बदलता है.
• DeviceConfigurationOverride.FontWeightAdjustment(): इससे सिस्टम फ़ॉन्ट की मोटाई में किए गए बदलाव को बदला जा सकता है.
• DeviceConfigurationOverride.ForcedSize(): इससे डिवाइस के साइज़ के बावजूद, एक तय जगह का इस्तेमाल किया जाता है.
• DeviceConfigurationOverride.LayoutDirection(): यह layout direction (बाएं से दाएं या दाएं से बाएं) को बदलता है.
• DeviceConfigurationOverride.Locales(): इससे locale की वैल्यू बदल जाती है.
• DeviceConfigurationOverride.RoundScreen(): अगर स्क्रीन गोल है, तो यह वैल्यू, डिफ़ॉल्ट वैल्यू को बदल देती है.

किसी खास ओवरराइड को लागू करने के लिए, जांच किए जा रहे कॉन्टेंट को DeviceConfigurationOverride() टॉप-लेवल फ़ंक्शन के कॉल में रैप करें. साथ ही, लागू किए जाने वाले ओवरराइड को पैरामीटर के तौर पर पास करें.

उदाहरण के लिए, यहां दिए गए कोड में DeviceConfigurationOverride.ForcedSize() ओवरराइड का इस्तेमाल करके, डेंसिटी को स्थानीय तौर पर बदला गया है. इससे MyScreen कंपोज़ेबल को बड़े लैंडस्केप विंडो में रेंडर किया जा सकेगा. भले ही, जिस डिवाइस पर टेस्ट चल रहा है वह सीधे तौर पर उस विंडो के साइज़ के साथ काम न करता हो:

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.ForcedSize(DpSize(1280.dp, 800.dp))
    ) {
        MyScreen() // Will be rendered in the space for 1280dp by 800dp without clipping.
    }
}
DeviceConfigurationOverrideSnippets.kt

एक साथ कई ओवरराइड लागू करने के लिए, DeviceConfigurationOverride.then() का इस्तेमाल करें:

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.FontScale(1.5f) then
            DeviceConfigurationOverride.FontWeightAdjustment(200)
    ) {
        Text(text = "text with increased scale and weight")
    }
}
DeviceConfigurationOverrideSnippets.kt

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

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