اگر در توسعه پلتفرم اندروید تازه کار هستید، ممکن است این مثال کامل از افزودن یک باینری کاملاً جدید GTest (که گاهی اوقات به آن تست "بومی" نیز گفته می شود) از ابتدا برای نشان دادن گردش کار معمولی مفید باشد. برای اطلاعات بیشتر در مورد چارچوب GTest برای C++، برای مستندات بیشتر به سایت پروژه GTest مراجعه کنید.
این راهنما از Hello 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 یا زیر شاخه جدید ایجاد شده را با فایل‌هایی مشابه آنچه در فهرست 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 کافی است. برای جزئیات بیشتر به پیکربندی تست ساده مراجعه کنید.
فایل پیکربندی پیچیده
برای استفاده از Trade Federation به جای آن، یک فایل پیکربندی آزمایشی برای مهار تست Android، Trade Federation بنویسید.
پیکربندی تست می‌تواند گزینه‌های راه‌اندازی دستگاه خاص و آرگومان‌های پیش‌فرض را برای تامین کلاس تست مشخص کند.
به صورت محلی بسازید و آزمایش کنید
برای رایج ترین موارد استفاده، از Atest استفاده کنید.
برای موارد پیچیده‌تر که نیاز به سفارشی‌سازی سنگین‌تر دارند، دستورالعمل‌های ابزار دقیق را دنبال کنید.