اگر در توسعه پلاتفرم Android تازه‌کار هستید، ممکن است این مثال کامل از افزودن یک باینری 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 در فایل ساخت حل می‌شود.
#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 مراجعه کنید
فایل پیکربندی ساده
هر واحد آزمایشی جدید باید فایل پیکربندی داشته باشد تا سیستم ساخت را با فراداده واحد، وابستگی‌های زمان ترجمه، و دستورالعمل‌های بسته‌بندی هدایت کند. در اکثر موارد، گزینه فایل Blueprint مبتنی بر Soong کافی است. برای جزئیات، به پیکربندی آزمایش ساده بروید.
فایل پیکربندی پیچیده
برای استفاده از Trade Federation، فایل پیکربندی آزمایشی برای مجموعه داده‌های تست Android، Trade Federation، بنویسید.
پیکربندی آزمایش می‌تواند گزینه‌های راه‌اندازی دستگاه ویژه و استدلال‌های پیش‌فرض را برای ارائه به کلاس آزمایش مشخص کند.
ساختن و آزمایش محلی
برای رایج‌ترین موارد استفاده، از Atest استفاده کنید.
برای موارد پیچیده‌تر که نیاز به سفارشی‌سازی سنگین‌تر دارند، دستورالعمل‌های ابزاربندی را دنبال کنید.