اگر در توسعه پلتفرم اندروید تازهکار هستید، ممکن است این مثال کامل از اضافه کردن یک فایل باینری کاملاً جدید GTest (که گاهی اوقات تست "بومی" نیز نامیده میشود) از ابتدا را برای نشان دادن گردش کار معمول مفید بیابید. برای اطلاعات بیشتر در مورد چارچوب GTest برای C++، به سایت پروژه GTest برای مستندات بیشتر مراجعه کنید.
این راهنما از آزمون Hello World GTest به عنوان مثال استفاده میکند. توصیه میکنیم قبل از ادامه، کد را به طور کامل بخوانید تا درک کلی از آن داشته باشید.
در مورد محل منبع تصمیم بگیرید
معمولاً تیم شما از قبل الگوی مشخصی از مکانها برای بررسی کد و مکانهایی برای اضافه کردن تستها دارد. اکثر تیمها یک مخزن گیت دارند یا آن را با تیمهای دیگر به اشتراک میگذارند، اما یک زیرشاخه اختصاصی دارند که شامل کد منبع کامپوننت است.
با فرض اینکه محل ریشه منبع کامپوننت شما در <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 وجود دارد، پر خواهید کرد. بخشهای زیر جزئیات بیشتری از هر فایل را توضیح میدهند.
کد منبع
برای مثال به Hello World GTest مراجعه کنید.
کد منبع برای آن مثال در اینجا حاشیهنویسی شده است:
#include <gtest/gtest.h>
فایل هدر برای GTest ضمیمه شده است. وابستگی فایل ضمیمه شده به طور خودکار با استفاده از BUILD_NATIVE_TEST در makefile برطرف میشود.
#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 مراجعه کنید.
فایل پیکربندی ساده
هر ماژول تست جدید باید یک فایل پیکربندی داشته باشد تا سیستم ساخت را با ابردادههای ماژول، وابستگیهای زمان کامپایل و دستورالعملهای بستهبندی هدایت کند. در بیشتر موارد، گزینه فایل Blueprint مبتنی بر Soong کافی است. برای جزئیات بیشتر به Simple Test Configuration مراجعه کنید.
فایل پیکربندی پیچیده
برای استفاده از Trade Federation به جای آن، یک فایل پیکربندی آزمایشی برای ابزار تست اندروید، Trade Federation ، بنویسید.
پیکربندی تست میتواند گزینههای تنظیم دستگاه خاص و آرگومانهای پیشفرض را برای ارائه کلاس تست مشخص کند.
ساخت و آزمایش به صورت محلی
برای رایجترین موارد استفاده، از Atest استفاده کنید.
برای موارد پیچیدهتر که نیاز به سفارشیسازی سنگینتری دارند، دستورالعملهای ابزار دقیق را دنبال کنید.