आसान बिल्ड कॉन्फ़िगरेशन

हर नए टेस्ट मॉड्यूल में एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए. इससे बिल्ड सिस्टम को मॉड्यूल के मेटाडेटा, कंपाइल-टाइम डिपेंडेंसी, और पैकेजिंग के निर्देशों के बारे में पता चलता है. Android अब टेस्ट कॉन्फ़िगरेशन को आसान बनाने के लिए, Soong बिल्ड सिस्टम का इस्तेमाल करता है.

Soong, Blueprint या .bp फ़ाइलों का इस्तेमाल करता है. ये फ़ाइलें, JSON जैसी होती हैं. इनमें मॉड्यूल बनाने के लिए, सामान्य तौर पर जानकारी दी जाती है. यह फ़ॉर्मैट, पिछली रिलीज़ में इस्तेमाल किए गए मेक-आधारित सिस्टम की जगह लेता है. पूरी जानकारी के लिए, Continuous Integration Dashboard पर Soong की रेफ़रंस फ़ाइलें देखें.

कस्टम टेस्टिंग करने या Android Compatibility Test Suite (CTS) का इस्तेमाल करने के लिए, जटिल टेस्ट कॉन्फ़िगरेशन का पालन करें.

उदाहरण

नीचे दी गई एंट्री, इस उदाहरण की ब्लूप्रिंट कॉन्फ़िगरेशन फ़ाइल से ली गई हैं: /platform_testing/tests/example/instrumentation/Android.bp

आपकी सुविधा के लिए, यहां एक स्नैपशॉट शामिल किया गया है:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

ध्यान दें कि शुरुआत में android_test एलान से पता चलता है कि यह एक टेस्ट है. android_app को शामिल करने से, यह पता चलेगा कि यह एक बिल्ड पैकेज है.

सेटिंग

इन सेटिंग के बारे में यहां बताया गया है:

    name: "HelloWorldTests",

android_test मॉड्यूल टाइप तय करते समय, name सेटिंग ज़रूरी होती है (ब्लॉक की शुरुआत में). इससे आपके मॉड्यूल को नाम मिलता है.साथ ही, इससे बनने वाले APK का नाम भी यही होता है और इसमें .apk सफ़िक्स जोड़ा जाता है. उदाहरण के लिए, इस मामले में, टेस्ट APK का नाम HelloWorldTests.apk है. इसके अलावा, यह आपके मॉड्यूल के लिए मेक टारगेट का नाम भी तय करता है, ताकि आप अपने टेस्ट मॉड्यूल और उसकी सभी डिपेंडेंसी बनाने के लिए make [options] <HelloWorldTests> का इस्तेमाल कर सकें.

    static_libs: ["androidx.test.runner"],

static_libs सेटिंग, बिल्ड सिस्टम को यह निर्देश देती है कि वह नाम वाले मॉड्यूल के कॉन्टेंट को मौजूदा मॉड्यूल के नतीजे वाले APK में शामिल करे. इसका मतलब है कि नाम वाले हर मॉड्यूल से .jar फ़ाइल जनरेट होने की उम्मीद की जाती है. साथ ही, इसके कॉन्टेंट का इस्तेमाल, कंपाइल करने के दौरान क्लासपाथ के रेफ़रंस को हल करने के लिए किया जाएगा. इसके अलावा, इसे नतीजे के तौर पर मिले APK में भी शामिल किया जाएगा.

androidx.test.runner मॉड्यूल, AndroidX Test Runner लाइब्रेरी के लिए पहले से बनाया गया है. इसमें टेस्ट रनर AndroidJUnitRunner शामिल है. AndroidJUnitRunner, JUnit4 टेस्टिंग फ़्रेमवर्क के साथ काम करता है. साथ ही, Android 10 में InstrumentationTestRunner की जगह इसका इस्तेमाल किया जाता है. Android ऐप्लिकेशन की टेस्टिंग के बारे में ज़्यादा जानने के लिए, Android पर ऐप्लिकेशन टेस्ट करना लेख पढ़ें.

अगर आपको नया इंस्ट्रूमेंटेशन मॉड्यूल बनाना है, तो आपको हमेशा androidx.test.runner लाइब्रेरी से शुरुआत करनी चाहिए. प्लैटफ़ॉर्म सोर्स ट्री में, ub-uiautomator, mockito-target, easymock जैसे अन्य काम के टेस्टिंग फ़्रेमवर्क भी शामिल हैं.

    certificate: "platform",

certificate सेटिंग, बिल्ड सिस्टम को यह निर्देश देती है कि वह APK को उसी सर्टिफ़िकेट से साइन करे जिससे कोर प्लैटफ़ॉर्म को साइन किया गया है. अगर आपके टेस्ट में, हस्ताक्षर से सुरक्षित अनुमति या एपीआई का इस्तेमाल किया जाता है, तो इसकी ज़रूरत होती है. ध्यान दें कि यह प्लैटफ़ॉर्म की लगातार टेस्टिंग के लिए सही है. हालांकि, इसका इस्तेमाल सीटीएस टेस्ट मॉड्यूल में नहीं किया जाना चाहिए. ध्यान दें कि इस उदाहरण में, सर्टिफ़िकेट की इस सेटिंग का इस्तेमाल सिर्फ़ उदाहरण के तौर पर किया गया है: उदाहरण के टेस्ट कोड के लिए, टेस्ट APK को खास प्लैटफ़ॉर्म सर्टिफ़िकेट से साइन करने की ज़रूरत नहीं होती.

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

अन्य मामलों में, आपको इस सेटिंग की ज़रूरत नहीं होती: बिल्ड सिस्टम, बिल्ड वैरिएंट के आधार पर, इसे डिफ़ॉल्ट रूप से शामिल किए गए सर्टिफ़िकेट से साइन करेगा. आम तौर पर, इसे dev-keys कहा जाता है.

    test_suites: ["device-tests"],

test_suites सेटिंग की मदद से, Trade Federation टेस्ट हार्नेस को टेस्ट आसानी से मिल जाता है. यहां CTS जैसे अन्य सुइट जोड़े जा सकते हैं, ताकि इस टेस्ट को शेयर किया जा सके.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

वैकल्पिक सेटिंग

यहां दी गई सेटिंग के बारे में जानकारी दी गई है. हालांकि, इनका इस्तेमाल करना ज़रूरी नहीं है:

    test_config: "path/to/hello_world_test.xml"

test_config सेटिंग, बिल्ड सिस्टम को यह निर्देश देती है कि आपके टेस्ट टारगेट को किसी खास कॉन्फ़िगरेशन की ज़रूरत है. डिफ़ॉल्ट रूप से, Android.bp के बगल में मौजूद AndroidTest.xml, कॉन्फ़िगरेशन से जुड़ा होता है.

    auto_gen_config: true

auto_gen_config सेटिंग से पता चलता है कि टेस्ट कॉन्फ़िगरेशन अपने-आप बनाना है या नहीं. अगर Android.bp के बगल में AndroidTest.xml मौजूद नहीं है, तो इस एट्रिब्यूट को'सही है' पर सेट करने की ज़रूरत नहीं है.

    require_root: true

require_root सेटिंग, बिल्ड सिस्टम को यह निर्देश देती है कि वह अपने-आप जनरेट होने वाले टेस्ट कॉन्फ़िगरेशन में RootTargetPreparer जोड़े. इससे यह गारंटी मिलती है कि टेस्ट, रूट अनुमतियों के साथ चलेगा.

    test_min_api_level: 29

test_min_api_level सेटिंग, बिल्ड सिस्टम को यह निर्देश देती है कि वह अपने-आप जनरेट होने वाले टेस्ट कॉन्फ़िगरेशन में MinApiLevelModuleController को जोड़े. जब Trade Federation, टेस्ट कॉन्फ़िगरेशन चलाता है, तो अगर डिवाइस प्रॉपर्टी ro.product.first_api_level < test_min_api_level है, तो टेस्ट को छोड़ दिया जाएगा.