मैपिंग की जांच करें

यह टेस्ट मैपिंग के बारे में कम शब्दों में जानकारी देता है. साथ ही, यह भी बताया गया है कि कैसे ने Android ओपन सोर्स प्रोजेक्ट (AOSP) में टेस्ट कॉन्फ़िगर करना शुरू कर दिया है.

टेस्ट मैपिंग के बारे में जानकारी

टेस्ट मैपिंग, गेरिट पर आधारित अप्रोच है. इसकी मदद से डेवलपर, और टेस्ट नियमों को सबमिट करने के बाद, उन्हें सीधे Android सोर्स ट्री में जोड़ दिया जाता है. उन ब्रांच और डिवाइसों के फ़ैसलों को भी टेस्ट किया जा सकता है जिनकी जांच बुनियादी ढांचे के लिए की जानी है. टेस्ट मैपिंग की परिभाषाएं, TEST_MAPPING नाम की JSON फ़ाइलें होती हैं. इन्हें आपके पास किया जा सकता है किसी भी सोर्स डायरेक्ट्री में डाला जा सकता है.

Atest में TEST_MAPPING फ़ाइलों का इस्तेमाल करके, जुड़ी हुई डायरेक्ट्री. टेस्ट मैपिंग की मदद से, आपके पास टेस्ट का एक जैसा सेट, Android सोर्स ट्री में कम से कम बदलाव करके, पहले से सबमिट की जाने वाली जांच की जा सकती है.

ये उदाहरण देखें:

• इसके लिए TEST_MAPPING में प्री-सबमिट टेस्ट जोड़ें services.core

• इसका इस्तेमाल करके tools/dexter के लिए, TEST_MAPPING में प्री-सबमिट टेस्ट जोड़ें इंपोर्ट

टेस्ट मैपिंग इन बातों पर निर्भर करती है: ट्रेड फ़ेडरेशन (टीएफ़) का टेस्ट हार्नेस एक्ज़ीक्यूशन और नतीजों की रिपोर्टिंग.

टेस्ट ग्रुप तय करें

टेस्ट मैपिंग ग्रुप, टेस्ट ग्रुप की मदद से टेस्ट करता है. टेस्ट ग्रुप का नाम यह हो सकता है: कोई भी स्ट्रिंग. उदाहरण के लिए, पहले से सबमिट करना, टेस्ट के ग्रुप का नाम हो सकता है चलाएं. इसके अलावा, पोस्टसबमिट भी ऐसे टेस्ट हो सकते हैं जिनका इस्तेमाल बदलावों के बाद बिल्ड मर्ज कर दिए जाते हैं.

पैकेज बिल्ड स्क्रिप्ट के नियम

ट्रेड फ़ेडरेशन टेस्ट हार्नेस के लिए किसी दिए गए बिल्ड के टेस्ट मॉड्यूल चलाने के लिए, इन मॉड्यूल में Soong या LOCAL_COMPATIBILITY_SUITE सेट के लिए, test_suites सेट इन दो सुइट में से एक के लिए:

• general-tests उन जांचों के लिए है जो डिवाइस के हिसाब से उपलब्ध सुविधाओं पर निर्भर नहीं करती हैं. जैसे, वेंडर के हिसाब से उपलब्ध हार्डवेयर, जो ज़्यादातर डिवाइसों में नहीं होता. ज़्यादातर जांच general-tests सुइट में होनी चाहिए, भले ही वे एक ABI या बिटनेस या हार्डवेयर सुविधाओं के लिए विशिष्ट हो, जैसे HWASan (यहां है हर एबीआई के लिए अलग test_suites टारगेट) और भले ही उन्हें चलाना ही क्यों न हो किसी डिवाइस पर.
• device-tests, उन टेस्ट के लिए है जो डिवाइस की खास क्षमताओं पर निर्भर करते हैं. आम तौर पर, ये जांच vendor/ में ही की जाती हैं. डिवाइस के हिसाब से, सिर्फ़ उन सुविधाओं के बारे में बताया जाता है जो किसी डिवाइस के लिए खास होती हैं. इसलिए, यह JUnit टेस्ट के साथ-साथ GTest टेस्ट पर भी लागू होता है. आम तौर पर, इन टेस्ट को general-tests के तौर पर मार्क किया जाना चाहिए, भले ही वे एबीआई के हिसाब से हों.

उदाहरण:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

टेस्ट सुइट में चलाने के लिए टेस्ट कॉन्फ़िगर करना

टेस्ट सुइट में कोई टेस्ट चलाने के लिए, यह टेस्ट:

• बिल्ड प्रोवाइडर उपलब्ध नहीं होना चाहिए.
• स्टोरेज खाली होने के बाद, स्टोरेज खाली करना ज़रूरी है. उदाहरण के लिए, कुछ समय के लिए टेस्ट के दौरान जनरेट की गई फ़ाइलें.
• सिस्टम की सेटिंग को डिफ़ॉल्ट या ओरिजनल वैल्यू में बदलना होगा.

• ऐसा नहीं होना चाहिए कि यह मान लिया जाए कि कोई डिवाइस किसी खास स्थिति में है. उदाहरण के लिए, रूट तैयार है. ज़्यादातर जांचों को चलाने के लिए, खास अधिकार की ज़रूरत नहीं होती है. अगर किसी टेस्ट के लिए, AndroidTest.xml में RootTargetPreparer के साथ रूट की ज़रूरत है, तो इसकी जानकारी देनी चाहिए. उदाहरण के लिए:

  <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
  

टेस्ट मैपिंग फ़ाइलें बनाएं

जिस डायरेक्ट्री के लिए टेस्ट कवरेज ज़रूरी है उसके लिए, TEST_MAPPING JSON फ़ाइल जोड़ें जो उदाहरण से मिलता-जुलता हो. इन नियमों से यह पक्का होता है कि टेस्ट पहले से सबमिट की गई इस बात की जांच की जाती है कि उस डायरेक्ट्री या उसकी किसी भी फ़ाइल में कोई फ़ाइल टच की गई है या नहीं सबडायरेक्ट्री.

एक उदाहरण फ़ॉलो करें

यहां TEST_MAPPING फ़ाइल का एक सैंपल दिया गया है (यह JSON फ़ॉर्मैट में है, लेकिन टिप्पणियों के साथ है समर्थित):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

एट्रिब्यूट सेट करें

उदाहरण में, presubmit और postsubmit दोनों के नाम हैं टेस्ट ग्रुप. ज़्यादा जानकारी के लिए, टेस्ट ग्रुप तय करना देखें टेस्ट ग्रुप के बारे में जानकारी.

आपके पास टेस्ट मॉड्यूल या ट्रेड फ़ेडरेशन इंटिग्रेशन टेस्ट का नाम सेट करने का विकल्प होता है नाम (टेस्ट एक्सएमएल फ़ाइल के लिए संसाधन पाथ, उदाहरण के लिए, uiautomator/uiautomator-demo) को name एट्रिब्यूट की वैल्यू में डालें. ध्यान दें कि name फ़ील्ड यह नहीं कर सकता name क्लास या टेस्ट करने के तरीके name का इस्तेमाल करें. सटीक तरीके से जांच करने के लिए, include-filter जैसे विकल्पों का इस्तेमाल करें. यहां जाएं: (include-filter इस्तेमाल का उदाहरण).

किसी टेस्ट की host सेटिंग से पता चलता है कि वह होस्ट पर चलने वाला डिवाइसलेस टेस्ट है या नहीं. इसके लिए, डिफ़ॉल्ट वैल्यू false है. इसका मतलब है कि टेस्ट इसे चलाने के लिए डिवाइस ज़रूरी है. इन टेस्ट टाइप का इस्तेमाल किया जा सकता है इसके लिए HostGTest: JUnit के लिए GTest बाइनरी और HostTest टेस्ट.

file_patterns एट्रिब्यूट की मदद से, रेगुलर एक्सप्रेशन स्ट्रिंग की सूची सेट की जा सकती है. इससे किसी भी सोर्स कोड फ़ाइल के रिलेटिव पाथ (TEST_MAPPING फ़ाइल वाली डायरेक्ट्री के हिसाब से) से मैच किया जा सकता है. उदाहरण में, जांच CtsWindowManagerDeviceTestCases सिर्फ़ तब सबमिट करने से पहले चलती है, जब Window या Activity से शुरू होने वाली कोई ऐसी Java फ़ाइल बदली जाती है जो TEST_MAPPING फ़ाइल या उसकी किसी सबडायरेक्ट्री में मौजूद होती है. JSON फ़ाइल में, बैकस्लैश `` को एस्केप किया जाना चाहिए.

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

options एट्रिब्यूट में, ट्रेडेड कमांड लाइन के अन्य विकल्प मौजूद हैं.

किसी दिए गए टेस्ट के लिए उपलब्ध विकल्पों की पूरी सूची पाने के लिए, इसे चलाएं:

tradefed.sh run commandAndExit [test_module] --help

इससे संदर्भ लें Trafed में विकल्प को मैनेज करना देखें.

Atest की मदद से टेस्ट चलाना

टेस्ट से जुड़े नियमों को पहले से ही स्थानीय तौर पर लागू करने के लिए:

1. उस डायरेक्ट्री पर जाएं जिसमें TEST_MAPPING फ़ाइल है.

2. निर्देश चलाएं:

   atest
   

मौजूदा फ़ाइल की TEST_MAPPING फ़ाइलों में, पहले से सबमिट किए गए सभी टेस्ट कॉन्फ़िगर कर दिए गए हैं डायरेक्ट्री और इसकी पैरंट डायरेक्ट्री चलती हैं. Aटेस्ट दो टेस्ट का पता लगाता है और चलाता है सबमिट करें (A और B).

यह, TEST_MAPPING में प्री-सबमिट टेस्ट चलाने का सबसे आसान तरीका है फ़ाइलें, मौजूदा वर्किंग डायरेक्ट्री (CWD) और पैरंट डायरेक्ट्री में मौजूद हैं. एटेस्ट CWD और इसकी पैरंट फ़ाइल में TEST_MAPPING फ़ाइल का पता लगाता है और उसका इस्तेमाल करता है डायरेक्ट्री में जा सकते हैं.

स्ट्रक्चर का सोर्स कोड

इस उदाहरण में, TEST_MAPPING फ़ाइलों को कॉन्फ़िगर करने का तरीका बताया गया है सोर्स ट्री:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

src/TEST_MAPPING का कॉन्टेंट:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

src/project_1/TEST_MAPPING का कॉन्टेंट:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

src/project_2/TEST_MAPPING का कॉन्टेंट:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

टारगेट डायरेक्ट्री की जानकारी दें

TEST_MAPPING फ़ाइलों में टेस्ट चलाने के लिए, एक टारगेट डायरेक्ट्री तय की जा सकती है डायरेक्ट्री. यह निर्देश दो टेस्ट (A, B) चलाता है:

atest --test-mapping src/project_1

सबमिट करने के बाद की जांच के नियम लागू करें

इस निर्देश का इस्तेमाल, इसमें बताए गए पोस्टसबमिट की जांच करने के नियमों को चलाने के लिए भी किया जा सकता है src_path में TEST_MAPPING (CWD पर डिफ़ॉल्ट रूप से सेट होती है) और इसकी पैरंट डायरेक्ट्री:

atest [--test-mapping] [src_path]:postsubmit

सिर्फ़ ऐसी जांच करें जिनके लिए किसी डिवाइस की ज़रूरत न हो

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

atest [--test-mapping] --host

टेस्ट ग्रुप की पहचान करें

Atest कमांड में टेस्ट ग्रुप तय किए जा सकते हैं. यह निर्देश चलता है src/project_1 डायरेक्ट्री में मौजूद फ़ाइलों से जुड़े सभी postsubmit टेस्ट करते हैं, जो सिर्फ़ एक टेस्ट (C) मौजूद होता है.

इसके अलावा, ग्रुप की परवाह किए बिना सभी टेस्ट करने के लिए, :all का इस्तेमाल किया जा सकता है. यह कमांड चार टेस्ट (A, B, C, X) चलाता है:

atest --test-mapping src/project_1:all

सबडायरेक्ट्री शामिल करें

डिफ़ॉल्ट रूप से, Atest में TEST_MAPPING में टेस्ट सिर्फ़ पहले से सबमिट होते हैं CWD में TEST_MAPPING फ़ाइल में कॉन्फ़िगर की गई जांचों की संख्या (या दी गई डायरेक्ट्री) और इसकी पैरंट डायरेक्ट्री. अगर आपको सभी सबडायरेक्ट्री में TEST_MAPPING फ़ाइलें, इसके लिए --include-subdir विकल्प का इस्तेमाल करें Atest को भी उन टेस्ट को शामिल करने के लिए कहें.

atest --include-subdir

--include-subdir विकल्प के बिना, Atest सिर्फ़ टेस्ट A चलाता है. --include-subdir विकल्प की मदद से, Atest दो टेस्ट (A, B) चलाता है.

लाइन-लेवल की टिप्पणी करने की सुविधा उपलब्ध है

TEST_MAPPING को बेहतर बनाने के लिए, लाइन-लेवल पर // फ़ॉर्मैट की टिप्पणी जोड़ी जा सकती है उसके बाद आने वाली सेटिंग के विवरण वाली फ़ाइल होगी. ATest और ट्रेड फ़ेडरेशन TEST_MAPPING को बिना टिप्पणियों वाले मान्य JSON फ़ॉर्मैट में प्रीप्रोसेस करें. सेव रखने के लिए JSON फ़ाइल को हटाया गया, सिर्फ़ लाइन-लेवल की // फ़ॉर्मैट वाली टिप्पणी समर्थित है.

उदाहरण:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}