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

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

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

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

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

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

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

इसे पाने का एक सामान्य पैटर्न यह है कि आप AndroidComposeTestRule का इस्तेमाल करके कोई गतिविधि न हो, जैसे कि ComponentActivity.

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() टॉप-लेवल फ़ंक्शन, ओवरराइड को पास कर रहा है पैरामीटर के तौर पर लागू करने के लिए.

उदाहरण के लिए, नीचे दिया गया कोड सघनता बदलने के लिए 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 के कुछ पहलुओं के लिए अब भी मददगार हो सकती है टेस्टिंग हो रही है.