افزودن GoogleTests جدید (GTests)

با مجموعه‌ها، منظم بمانید ذخیره و دسته‌بندی محتوا براساس اولویت‌های شما.

اگر در توسعه پلتفرم اندروید تازه کار هستید، ممکن است این مثال کامل از افزودن یک باینری کاملاً جدید 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 نمونه وجود دارد، پر می کنید. بخش های زیر جزئیات بیشتر هر فایل را توضیح خواهند داد.

کد منبع

برای مثال به 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 استفاده کنید.

برای موارد پیچیده‌تر که نیاز به سفارشی‌سازی سنگین‌تر دارند، دستورالعمل‌های ابزار دقیق را دنبال کنید.