यदि आप एंड्रॉइड प्लेटफॉर्म के विकास के लिए नए हैं, तो आपको इसमें शामिल विशिष्ट वर्कफ़्लो को प्रदर्शित करने के लिए एकदम नए 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
| \-- ...
\-- ...
संरचना के बावजूद, आप tests निर्देशिका या नई बनाई गई उप निर्देशिका को नमूना गेरिट परिवर्तन में native निर्देशिका में समान फ़ाइलों के साथ पॉप्युलेट कर देंगे। नीचे दिए गए अनुभागों में प्रत्येक फ़ाइल के बारे में अधिक जानकारी दी जाएगी।
सोर्स कोड
उदाहरण के लिए हैलो वर्ल्ड जीटेस्ट का संदर्भ लें।
उस उदाहरण के लिए स्रोत कोड यहाँ टिप्पणी की गई है:
#include <gtest/gtest.h>
शीर्ष लेख फ़ाइल GTest के लिए शामिल है। मेकफाइल में BUILD_NATIVE_TEST उपयोग करके शामिल फ़ाइल निर्भरता स्वचालित रूप से हल हो जाती है।
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
TEST मैक्रो का उपयोग करके GTests लिखे गए हैं: पहला पैरामीटर टेस्ट केस नाम है, और दूसरा टेस्ट नाम है। परीक्षण बाइनरी नाम के साथ, वे परिणाम डैशबोर्ड में निम्न पदानुक्रम बनाते हैं:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
GTest के साथ परीक्षण लिखने के बारे में अधिक जानकारी के लिए, GTest दस्तावेज़ीकरण देखें
सरल कॉन्फ़िगरेशन फ़ाइल
मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए प्रत्येक नए परीक्षण मॉड्यूल में कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। ज्यादातर मामलों में, सूंग-आधारित, ब्लूप्रिंट फ़ाइल विकल्प पर्याप्त होता है। विवरण के लिए सरल परीक्षण विन्यास देखें।
जटिल कॉन्फ़िगरेशन फ़ाइल
इसके बजाय ट्रेड फेडरेशन का उपयोग करने के लिए, एंड्रॉइड के टेस्ट हार्नेस, ट्रेड फेडरेशन के लिए एक परीक्षण कॉन्फ़िगरेशन फ़ाइल लिखें।
परीक्षण कॉन्फ़िगरेशन विशेष उपकरण सेटअप विकल्प और परीक्षण वर्ग की आपूर्ति के लिए डिफ़ॉल्ट तर्क निर्दिष्ट कर सकता है।
स्थानीय रूप से निर्माण और परीक्षण करें
सबसे आम उपयोग के मामलों के लिए, Atest को नियोजित करें।
अधिक जटिल मामलों के लिए भारी अनुकूलन की आवश्यकता होती है, इंस्ट्रूमेंटेशन निर्देशों का पालन करें।