إذا كنت مبتدئًا في مجال تطوير نظام Android الأساسي، قد تكتمل هذه الخطوة مثال على إضافة برنامج ثنائي جديد كليًا في GTest (يسمى أيضًا "أصلي" لاختباره) من البداية ومفيدًا لإثبات سير العمل النموذجي المتضمنة. بالنسبة لمزيد من المعلومات حول إطار عمل GTest C++، راجع مشروع GTest للاطّلاع على مستندات إضافية.
يستخدم هذا الدليل أداة Hello World GTest كمثال. ننصحك بقراءة الرمز البرمجي للحصول على فهم تقريبي قبل المتابعة.
تحديد موقع مصدر
عادةً ما يكون لدى فريقك نمط محدد للأماكن التي يجب التحقق منها في الرموز البرمجية، والأماكن التي يمكن إضافة الاختبارات إليها. يمتلك معظم الفريق مستودع جيت واحد، أو مشاركة واحد مع فرق أخرى، ولكن لديك دليل فرعي مخصص يحتوي على رمز المصدر المكون.
على افتراض أنّ الموقع الجذر لمصدر المكوّن هو <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!");
}
تُكتب اختبارات GTest باستخدام وحدة الماكرو TEST: المعلمة الأولى هي حالة الاختبار
والاسم الثاني هو اسم الاختبار. جنبًا إلى جنب مع الاسم الثنائي الاختباري، فإنها تشكل
التسلسل الهرمي التالي في لوحة بيانات النتائج:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
لمزيد من المعلومات حول كتابة الاختبارات باستخدام GTest، راجِع مستندات GTest.
ملف الإعداد البسيط
يجب أن تحتوي كل وحدة اختبار جديدة على ملف إعداد لتوجيهها نظام التصميم مع بيانات التعريف للوحدة النمطية، وتبعيات وقت التجميع، وحزمة على التعليمات في معظم الحالات، يكون خيار ملف Blueprint المستند إلى Sung هو كافية. راجِع إعدادات الاختبار البسيط لمعرفة التفاصيل.
ملف الإعداد المعقد
لاستخدام اتحاد تجاري بدلاً من ذلك، اكتب تكوين اختبار لتسهم اختبار Android، اتحاد التجارة.
يمكن أن تحدد إعدادات الاختبار خيارات خاصة لإعداد الجهاز وخيارات الإعداد التلقائي وسيطات لتزويد فئة الاختبار.
إنشاء التطبيقات واختبارها محليًا
وبالنسبة إلى حالات الاستخدام الأكثر شيوعًا، استخدم تأكيد:
وبالنسبة إلى الحالات الأكثر تعقيدًا التي تتطلب قدرًا أكبر من التخصيص، يُرجى اتباع تعليمات الأدوات.