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

Compose ऐप्लिकेशन को, पहले से इस्तेमाल किए जा रहे तरीकों और पैटर्न की मदद से टेस्ट किया जा सकता है.

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

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

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

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

अक्सर, आपको composeTestRule.setContent का इस्तेमाल करके, जांचे जा रहे कॉन्टेंट को सेट करना होता है. साथ ही, आपको गतिविधि के संसाधनों को ऐक्सेस करना भी होता है. उदाहरण के लिए, यह बताने के लिए कि दिखाया गया टेक्स्ट, स्ट्रिंग संसाधन से मेल खाता है या नहीं. हालांकि, अगर गतिविधि पहले से ही createAndroidComposeRule() को कॉल करती है, तो 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()

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

खाते के स्टेटस के वापस आ जाने की पुष्टि करना

पुष्टि करें कि गतिविधि या प्रोसेस को फिर से बनाने पर, आपके Compose एलिमेंट की स्थिति सही तरीके से वापस आ गई हो. 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(): लेआउट की दिशा (बाएं से दाएं या दाएं से बाएं) को बदल देता है.
• 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: यह टूल, व्यू पर आधारित यूज़र इंटरफ़ेस (यूआई) के लिए है. हालांकि, Compose की जांच के कुछ पहलुओं के लिए, Espresso के बारे में जानकारी मददगार हो सकती है.