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

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

Soong, ब्लूप्रिंट या .bp फ़ाइलों का इस्तेमाल करता है. ये फ़ाइलें, JSON की तरह ही, बने जाने वाले मॉड्यूल के बारे में आसानी से जानकारी देने वाली फ़ाइलें होती हैं. यह फ़ॉर्मैट, पिछली रिलीज़ में इस्तेमाल किए गए Make-based सिस्टम की जगह लेता है. पूरी जानकारी के लिए, लगातार इंटिग्रेशन डैशबोर्ड पर Soong रेफ़रंस फ़ाइलें देखें.

कस्टम टेस्टिंग को शामिल करने या Android कंपैटबिलिटी टेस्ट सुइट (सीटीएस) का इस्तेमाल करने के लिए, मुश्किल टेस्ट कॉन्फ़िगरेशन का इस्तेमाल करें.

उदाहरण

यहां दी गई एंट्री, ब्लूप्रिंट कॉन्फ़िगरेशन फ़ाइल के इस उदाहरण से ली गई हैं: /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 टेस्टिंग फ़्रेमवर्क के साथ काम करता है और इसे InstrumentationTestRunner को Android 10 में बदल दिया गया है. 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 टेस्ट हार्नेस को टेस्ट आसानी से मिल जाता है. यहां अन्य सुइट भी जोड़े जा सकते हैं, जैसे कि सीटीएस, ताकि इस जांच को शेयर किया जा सके.

${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 सेटिंग, बिल्ड सिस्टम को अपने-आप जनरेट होने वाले टेस्ट कॉन्फ़िगरेशन में RootTargetProductr को जोड़ने का निर्देश देती है. इससे यह गारंटी मिलती है कि टेस्ट, रूट अनुमतियों के साथ चलेगा.

    test_min_api_level: 29

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