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

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

مصدر الرمز

رؤية اختبار الأصلية مرحبا العالم على سبيل المثال.

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

#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 كافيًا. انظر تكوين اختبار بسيط للحصول على التفاصيل.

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

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

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

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

لمعظم حالات الاستخدام المشترك، توظيف ATEST .

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