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