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

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

राज्य से वापस लाने की पुष्टि करें

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