إذا كنت جديدًا في مجال تطوير منصة 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.
بالنسبة إلى الحالات الأكثر تعقيدًا التي تتطلّب تخصيصًا أكبر، اتّبِع تعليمات القياس.