एक नया मूल परीक्षण उदाहरण जोड़ना

यदि आप एंड्रॉइड प्लेटफॉर्म विकास के लिए नए हैं, तो आपको इसमें शामिल विशिष्ट वर्कफ़्लो को प्रदर्शित करने के लिए उपयोगी स्क्रैच से एक नया मूल परीक्षण जोड़ने का यह पूरा उदाहरण मिल सकता है। इसके अलावा, यदि आप भी सी के लिए gtest ढांचे के साथ अपरिचित हैं ++, की समीक्षा करें 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 निर्देशिका या क्या में है के लिए इसी तरह फाइलों के साथ नव निर्मित उप निर्देशिका native नमूना Gerrit परिवर्तन में निर्देशिका। नीचे दिए गए अनुभाग प्रत्येक फ़ाइल के अधिक विवरण में व्याख्या करेंगे।

सोर्स कोड

देखें नमस्ते विश्व मूल निवासी टेस्ट एक उदाहरण के लिए।

एनोटेट स्रोत कोड नीचे सूचीबद्ध है:

#include <gtest/gtest.h>

हैडर फ़ाइल gtest के लिए शामिल है। नोट शामिल है कि फाइल निर्भरता स्वचालित रूप से का उपयोग करके हल हो गई है BUILD_NATIVE_TEST makefile में

#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 के साथ परीक्षण लिखने के बारे में अधिक जानकारी के लिए, इसके दस्तावेज़ देखें:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

सरल विन्यास फाइल

प्रत्येक नए परीक्षण मॉड्यूल में मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। ज्यादातर मामलों में, सूंग-आधारित, ब्लूप्रिंट फ़ाइल विकल्प पर्याप्त है। देखें सरल टेस्ट विन्यास जानकारी के लिए।

जटिल विन्यास फाइल

बजाय ट्रेड फेडरेशन का उपयोग करने के लिए, Android के परीक्षण दोहन, के लिए एक परीक्षण विन्यास फाइल लिखने ट्रेड फेडरेशन

परीक्षण कॉन्फ़िगरेशन परीक्षण वर्ग की आपूर्ति के लिए विशेष उपकरण सेटअप विकल्प और डिफ़ॉल्ट तर्क निर्दिष्ट कर सकता है।

स्थानीय रूप से निर्माण और परीक्षण करें

सबसे आम उपयोग के मामलों के लिए, काम atest

और अधिक जटिल भारी अनुकूलन की आवश्यकता होती है मामलों के लिए, का पालन करें इंस्ट्रूमेंटेशन निर्देश