Google अश्वेत समुदायों के लिए नस्लीय इक्विटी को आगे बढ़ाने के लिए प्रतिबद्ध है। देखो कैसे।
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

एक नया मूल परीक्षा उदाहरण जोड़ना

यदि आप एंड्रॉइड प्लेटफ़ॉर्म डेवलपमेंट के लिए नए हैं, तो आपको इसमें शामिल किए गए विशिष्ट वर्कफ़्लो को प्रदर्शित करने के लिए स्क्रैच से बिल्कुल नया देशी टेस्ट जोड़ने का यह पूरा उदाहरण मिल सकता है। इसके अलावा, यदि आप C ++ के लिए gtest फ्रेमवर्क से भी अपरिचित हैं, तो अतिरिक्त दस्तावेज के लिए gtest प्रोजेक्ट साइट की समीक्षा करें।

यह मार्गदर्शिका एक नमूने के रूप में कार्य करने के लिए अनुसरण परीक्षण का उपयोग करती है:

हैलो वर्ल्ड नेटिव टेस्ट

आगे बढ़ने से पहले किसी न किसी छाप को प्राप्त करने के लिए पहले कोड के माध्यम से ब्राउज़ करने की सिफारिश की जाती है।

स्रोत स्थान पर निर्णय लेना

आमतौर पर आपकी टीम में पहले से ही कोड में जांच करने के लिए और परीक्षण जोड़ने के लिए स्थानों का एक स्थापित पैटर्न होगा। अधिकांश टीम एकल git रिपॉजिटरी का मालिक है, या अन्य टीमों के साथ एक साझा करता है, लेकिन एक समर्पित उप निर्देशिका है जिसमें घटक स्रोत कोड होता है।

अपने घटक स्रोत के लिए मूल स्थान मानकर <component source root> , अधिकांश घटकों में इसके अंतर्गत src और tests फ़ोल्डर हैं, और कुछ अतिरिक्त फाइलें जैसे Android.mk (या अतिरिक्त .bp फ़ाइलों में टूट गई)।

जब से आप एक नया परीक्षण जोड़ रहे हैं, तो आपको संभवतः अपने घटक src बगल में tests निर्देशिका बनाने की आवश्यकता होगी, और इसे सामग्री के साथ आबाद करें।

कुछ मामलों में, आपकी टीम में अलग-अलग बायनेरिज़ में परीक्षणों के अलग-अलग सूटों को पैकेज करने की आवश्यकता के कारण tests के तहत आगे की निर्देशिका संरचनाएं हो सकती हैं। और इस मामले में, आपको tests तहत एक नई उप निर्देशिका बनाने की आवश्यकता होगी।

उदाहरण के लिए, यहां एकल tests फ़ोल्डर वाले घटकों के लिए एक विशिष्ट निर्देशिका रूपरेखा है:

 \
 <component source root>
  \-- Android.bp (component makefile)
  \-- AndroidTest.xml (test config file)
  \-- src (component source)
  |    \-- foo.cpp
  |    \-- ...
  \-- tests (test source root)
      \-- Android.bp (test makefile)
      \-- src (test source)
          \-- foo_test.cpp
          \-- ...
 

और यहाँ कई परीक्षण स्रोत निर्देशिका वाले घटकों के लिए एक विशिष्ट निर्देशिका रूपरेखा है:

 \
 <component source root>
  \-- Android.bp (component makefile)
  \-- AndroidTest.xml (test config file)
  \-- src (component source)
  |    \-- foo.cpp
  |    \-- ...
  \-- tests (test source root)
      \-- Android.bp (test makefile)
      \-- testFoo (sub test source root)
      |   \-- Android.bp (sub test makefile)
      |   \-- src (sub test source)
      |       \-- test_foo.cpp
      |       \-- ...
      \-- testBar
      |   \-- Android.bp
      |   \-- src
      |       \-- test_bar.cpp
      |       \-- ...
      \-- ...
 

संरचना की परवाह किए बिना, आप tests निर्देशिका या नव निर्मित उप निर्देशिका को उसी तरह की फाइलों के साथ समाप्‍त करेंगे जो सैंपल गेरिट परिवर्तन में native निर्देशिका में है। नीचे दिए गए अनुभाग प्रत्येक फ़ाइल के आगे विवरण में बताएंगे।

सोर्स कोड

एक उदाहरण के लिए हैलो वर्ल्ड नेटिव टेस्ट देखें।

एनोटेट स्रोत कोड नीचे सूचीबद्ध है:

 #include <gtest/gtest.h>
 

हैडर फ़ाइल में gtest शामिल है। नोट करें कि फ़ाइल निर्भरता को स्वचालित रूप से BUILD_NATIVE_TEST में BUILD_NATIVE_TEST का उपयोग करके हल किया गया है

 #include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}
 

TEST मैक्रो का उपयोग करके संदर्भ लिखे गए हैं: पहला पैरामीटर टेस्ट केस नाम है, और दूसरा टेस्ट नाम है; परीक्षण बाइनरी नाम के साथ, वे परिणाम डैशबोर्ड में दिखाई देने पर नीचे पदानुक्रम बनाते हैं:

 <test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...
 

Gtest के साथ परीक्षण लिखने के बारे में अधिक जानकारी के लिए, इसका प्रलेखन देखें:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

सरल विन्यास फाइल

प्रत्येक नए परीक्षण मॉड्यूल में मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। ज्यादातर मामलों में, Soong- आधारित, ब्लूप्रिंट फ़ाइल विकल्प पर्याप्त है। विवरण के लिए सरल परीक्षण कॉन्फ़िगरेशन देखें।

जटिल विन्यास फाइल

इसके बजाय ट्रेड फेडरेशन का उपयोग करने के लिए, एंड्रॉइड के टेस्ट हार्नेस, ट्रेड फेडरेशन के लिए एक परीक्षण कॉन्फ़िगरेशन फ़ाइल लिखें।

परीक्षण कॉन्फ़िगरेशन विशेष डिवाइस सेटअप विकल्प और डिफ़ॉल्ट तर्क परीक्षण कक्षा की आपूर्ति करने के लिए निर्दिष्ट कर सकता है।

स्थानीय रूप से निर्माण और परीक्षण करें

सबसे आम उपयोग के मामलों के लिए, Atest को नियोजित करें

अधिक जटिल मामलों के लिए भारी अनुकूलन की आवश्यकता होती है, इंस्ट्रूमेंटेशन निर्देशों का पालन करें