नए GoogleTests (GTests) जोड़ें

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

यह मार्गदर्शिका एक उदाहरण के रूप में हैलो वर्ल्ड जीटीटेस्ट का उपयोग करती है। हम अनुशंसा करते हैं कि आगे बढ़ने से पहले कोड को अच्छी तरह से समझने के लिए उसे पढ़ लें।

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

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

यह मानते हुए कि आपके घटक स्रोत का मूल स्थान <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
      |       \-- ...
      \-- ...

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

सोर्स कोड

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

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

#include <gtest/gtest.h>

जीटीटेस्ट के लिए हेडर फ़ाइल शामिल है। मेकफ़ाइल में 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 के साथ परीक्षण लिखने के बारे में अधिक जानकारी के लिए, GTest दस्तावेज़ देखें

सरल कॉन्फ़िगरेशन फ़ाइल

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

जटिल कॉन्फ़िगरेशन फ़ाइल

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

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

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

सबसे आम उपयोग के मामलों के लिए, एटेस्ट का उपयोग करें।

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