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