अगर आपने 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 बदलाव में native डायरेक्ट्री में मौजूद हैं. यहां दिए गए सेक्शन में, हर फ़ाइल के बारे में ज़्यादा जानकारी दी गई है.
सोर्स कोड
उदाहरण के लिए, Hello World GTest देखें.
उस उदाहरण के सोर्स कोड पर यहां एनोटेशन किया गया है:
#include <gtest/gtest.h>
GTest के लिए हेडर फ़ाइल शामिल करें. मेकफ़ाइल में 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 का दस्तावेज़ देखें
आसान कॉन्फ़िगरेशन फ़ाइल
हर नए टेस्ट मॉड्यूल में एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए, ताकि मॉड्यूल के मेटाडेटा, कंपाइल के समय की डिपेंडेंसी, और पैकेजिंग के निर्देशों के साथ बिल्ड सिस्टम को निर्देश दिया जा सके. ज़्यादातर मामलों में, Soong पर आधारित Blueprint फ़ाइल का विकल्प काफ़ी होता है. ज़्यादा जानकारी के लिए, सिंपल टेस्ट कॉन्फ़िगरेशन देखें.
कॉम्प्लेक्स कॉन्फ़िगरेशन फ़ाइल
इसके बजाय, Trade Federation का इस्तेमाल करने के लिए, Android के टेस्ट हार्नेस, Trade Federation के लिए टेस्ट कॉन्फ़िगरेशन फ़ाइल लिखें.
टेस्ट कॉन्फ़िगरेशन में, डिवाइस के सेटअप के खास विकल्प और टेस्ट क्लास देने के लिए डिफ़ॉल्ट आर्ग्युमेंट तय किए जा सकते हैं.
स्थानीय तौर पर बनाना और टेस्ट करना
इस्तेमाल के सबसे सामान्य उदाहरणों के लिए, Atest का इस्तेमाल करें.
ज़्यादा जटिल मामलों में, ज़्यादा कस्टमाइज़ेशन की ज़रूरत होती है. ऐसे मामलों में, इंस्ट्रूमेंटेशन के निर्देशों का पालन करें.