नए GoogleTests जोड़ना (GTests)

यदि आप Android प्लेटफ़ॉर्म विकास के लिए नए हैं, तो आपको इसमें शामिल विशिष्ट वर्कफ़्लो को प्रदर्शित करने के लिए बिल्कुल नए GTest बाइनरी (जिसे कभी-कभी "मूल" परीक्षण भी कहा जाता है) जोड़ने का यह पूरा उदाहरण मिल सकता है। 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 निर्देशिका या नई बनाई गई उप निर्देशिका को नमूना gerrit परिवर्तन में native निर्देशिका में समान फ़ाइलों के साथ पॉप्युलेट कर देंगे। नीचे दिए गए अनुभाग प्रत्येक फ़ाइल के अधिक विवरण में व्याख्या करेंगे।

सोर्स कोड

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

उस उदाहरण के लिए स्रोत कोड यहाँ एनोटेट किया गया है:

#include <gtest/gtest.h>

GTest के लिए शीर्षलेख फ़ाइल शामिल है। BUILD_NATIVE_TEST में BUILD_NATIVE_TEST का उपयोग करके शामिल फ़ाइल निर्भरता स्वचालित रूप से हल हो जाती है।

#include <stdio.h>

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

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

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

GTest के साथ परीक्षण लिखने के बारे में अधिक जानकारी के लिए , GTest दस्तावेज़ीकरण देखें

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

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

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

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

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

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

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

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