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