अगर आपने Android प्लैटफ़ॉर्म के डेवलपमेंट का इस्तेमाल पहले कभी नहीं किया है, तो आपको नए सिरे से GTest बाइनरी (इसे कभी-कभी "नेटिव" टेस्ट भी कहा जाता है) जोड़ने का यह पूरा उदाहरण दिख सकता है. इससे यह जानने में मदद मिलेगी कि किस तरह के वर्कफ़्लो में शामिल है. C++ के लिए GTest फ़्रेमवर्क के बारे में ज़्यादा जानकारी के लिए, GTest प्रोजेक्ट साइट पर जाएं.
इस गाइड में, उदाहरण के तौर पर Hello World GTest का इस्तेमाल किया गया है. हमारा सुझाव है कि आगे बढ़ने से पहले कोड को अच्छी तरह से समझ लें.
सोर्स की जगह तय करना
आम तौर पर, आपकी टीम के पास चेक-इन कोड और टेस्ट जोड़ने के लिए जगहों का एक पहले से तय पैटर्न होगा. ज़्यादातर टीम एक ही GitHub रिपॉज़िटरी का मालिक होती है या किसी एक टीम को दूसरी टीमों के साथ शेयर करती है, लेकिन उनके पास एक खास सब डायरेक्ट्री होती है जिसमें कॉम्पोनेंट का सोर्स कोड होता है.
यह मानते हुए कि आपके कॉम्पोनेंट सोर्स की रूट लोकेशन <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 डायरेक्ट्री में मौजूद हैं. यहां दिए गए सेक्शन में, हर फ़ाइल के बारे में ज़्यादा जानकारी दी गई है.
सोर्स कोड
उदाहरण के लिए, नमस्ते 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 का इस्तेमाल करें.
ज़्यादा जटिल मामलों में, ज़्यादा कस्टमाइज़ेशन की ज़रूरत होती है. ऐसे मामलों में, इंस्ट्रूमेंटेशन के निर्देशों का पालन करें.