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