अगर Android प्लैटफ़ॉर्म डेवलपमेंट के बारे में आपको पहले पता नहीं है, तो बिलकुल नई GTest बाइनरी जोड़ने का उदाहरण (इसे कभी-कभी "नेटिव" भी कहा जाता है) परीक्षण) को शुरुआत से उपयोगी साबित किया है. इसके लिए GTest फ़्रेमवर्क पर अतिरिक्त जानकारी C++, GTest प्रोजेक्ट देखें साइट पर जाएं.
इस गाइड में Hey World GTest का इस्तेमाल किया गया है पर जाएं. हमारा सुझाव है कि आगे बढ़ने से पहले, कोड को अच्छी तरह से पढ़ लें, ताकि आपको इसकी जानकारी मिल सके.
सोर्स की जगह तय करें
आम तौर पर, आपकी टीम के पास जांच करने के लिए पहले से ही जगहों का एक तय पैटर्न होगा और टेस्ट जोड़ने की जगहें शामिल की हैं. ज़्यादातर टीम के पास एक ही git रिपॉज़िटरी होती है या वे एक रिपॉज़िटरी को दूसरी टीमों के साथ शेयर करती हैं. हालांकि, उनके पास एक खास सब-डायरेक्ट्री होती है जिसमें कॉम्पोनेंट का सोर्स कोड होता है.
यह मानते हुए कि आपके कॉम्पोनेंट सोर्स की रूट लोकेशन <component source
root> है, ज़्यादातर कॉम्पोनेंट के तहत src और tests फ़ोल्डर होते हैं. साथ ही, कुछ कॉम्पोनेंट
अतिरिक्त फ़ाइलें, जैसे कि Android.mk या अलग-अलग .bp में बांटना
फ़ाइलें).
आप एक बिलकुल नया टेस्ट जोड़ रहे हैं, इसलिए शायद आपको
tests डायरेक्ट्री को जोड़ें, जो आपके कॉम्पोनेंट src के बगल में मौजूद होगा और इसे कॉन्टेंट से भर देगा.
कुछ मामलों में, आपकी टीम के पास 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!");
}
Gटेस्ट, TEST मैक्रो का इस्तेमाल करके लिखे जाते हैं: पहला पैरामीटर, टेस्ट केस है
दूसरा नाम है, और दूसरा टेस्ट का नाम. टेस्ट बाइनरी नाम के साथ मिलकर, वे
ये नतीजे हर क्रम में दिखेंगे:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
GTest के साथ टेस्ट लिखने के बारे में ज़्यादा जानकारी के लिए, GTest दस्तावेज़ देखें
आसान कॉन्फ़िगरेशन फ़ाइल
हर नए टेस्ट मॉड्यूल में एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए, ताकि मॉड्यूल के मेटाडेटा, कंपाइल के समय की डिपेंडेंसी, और पैकेजिंग के निर्देशों के साथ बिल्ड सिस्टम को निर्देश दिया जा सके. ज़्यादातर मामलों में, सूंग पर आधारित ब्लूप्रिंट फ़ाइल का विकल्प काफ़ी हैं. ज़्यादा जानकारी के लिए, आसान टेस्ट कॉन्फ़िगरेशन देखें.
कॉम्प्लेक्स कॉन्फ़िगरेशन फ़ाइल
इसके बजाय, ट्रेड फ़ेडरेशन का इस्तेमाल करने के लिए, टेस्ट कॉन्फ़िगरेशन लिखें फ़ाइल को Android के टेस्ट हार्नेस, Trade Feफ़ेडरेशन के लिए सबमिट किया.
टेस्ट कॉन्फ़िगरेशन, डिवाइस सेटअप के खास विकल्प और डिफ़ॉल्ट सेटिंग तय कर सकता है आर्ग्युमेंट का इस्तेमाल करें.
ऐप्लिकेशन को स्थानीय तौर पर बनाएं और टेस्ट करें
आम तौर पर इस्तेमाल किए जाने वाले उदाहरणों के लिए, यहां दिए गए तरीके अपनाएं एटेस्ट.
जिन मामलों में ज़्यादा कस्टमाइज़ करने की ज़रूरत होती है उनके लिए, नीचे दिए गए निर्देशों का पालन करें इंस्ट्रुमेंटेशन से जुड़े निर्देश शामिल करें.