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