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