تلتزم Google بتعزيز المساواة العرقية للمجتمعات السوداء. أنظر كيف.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

إضافة مثال اختبار أصلي جديد

إذا كنت جديدًا في تطوير نظام Android الأساسي ، فقد تجد هذا المثال الكامل لإضافة اختبار أصلي جديد تمامًا من الصفر مفيدًا لتوضيح سير العمل النموذجي المتضمن. بالإضافة إلى ذلك ، إذا لم تكن على دراية بإطار gtest لـ C ++ ، فالرجاء مراجعة موقع مشروع gtest للحصول على وثائق إضافية.

يستخدم هذا الدليل الاختبار التالي ليكون بمثابة عينة:

Hello World Native Test

يوصى باستعراض الرمز أولاً للحصول على انطباع تقريبي قبل المتابعة.

تحديد موقع المصدر

عادةً ما يكون لدى فريقك بالفعل نمط محدد من الأماكن للتحقق من الرمز ، وأماكن لإضافة الاختبارات. يمتلك معظم الفريق مستودع 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 الأصلي للحصول على مثال.

رمز المصدر المشروح مدرج أدناه:

 #include <gtest/gtest.h>
 

يتضمن ملف الرأس لـ gtest. لاحظ أنه يتم حل تبعية ملف التضمين تلقائيًا باستخدام BUILD_NATIVE_TEST في ملف makefile

 #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 ، راجع وثائقها:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

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

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

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

لاستخدام اتحاد التجارة بدلاً من ذلك ، اكتب ملف تكوين اختبار لحزام اختبار Android ، الاتحاد التجاري .

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

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

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

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