إضافة اختبارات Google جديدة (GTests)

إذا كنت جديدًا في تطوير نظام 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!");
}

تتم كتابة اختبارات GT باستخدام ماكرو TEST : المعلمة الأولى هي اسم حالة الاختبار، والثانية هي اسم الاختبار. بالإضافة إلى الاسم الثنائي للاختبار، فإنها تشكل التسلسل الهرمي التالي في لوحة معلومات النتيجة:

<test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...

لمزيد من المعلومات حول كتابة الاختبارات باستخدام GTest، راجع وثائق GTest

ملف التكوين البسيط

يجب أن تحتوي كل وحدة اختبار جديدة على ملف تكوين لتوجيه نظام الإنشاء باستخدام البيانات التعريفية للوحدة وتبعيات وقت الترجمة وتعليمات التعبئة. في معظم الحالات، يكون خيار ملف Blueprint المستند إلى Soong كافيًا. راجع تكوين الاختبار البسيط للحصول على التفاصيل.

ملف التكوين المعقد

لاستخدام Trade Union بدلاً من ذلك، اكتب ملف تكوين اختباري لأداة اختبار Android، Trade Union .

يمكن لتكوين الاختبار تحديد خيارات إعداد الجهاز الخاصة والوسائط الافتراضية لتوفير فئة الاختبار.

بناء واختبار محليا

بالنسبة لحالات الاستخدام الأكثر شيوعًا، استخدم Atest .

بالنسبة للحالات الأكثر تعقيدًا التي تتطلب تخصيصًا أكبر، اتبع تعليمات الأجهزة .