مقدمة للاختبار الآلي لملحقات WordPress باستخدام PHPUnit
نشرت: 2022-03-10يعد WordPress نظامًا شائعًا لإدارة المحتوى لإنشاء مواقع الويب لأنه من السهل البدء به ويتوفر الكثير من السمات والمكونات الإضافية لتوسيع مجموعة الميزات الخاصة به. السبب الرئيسي وراء احتواء WordPress على الكثير من المكونات الإضافية والسمات هو أنه من السهل على المطورين من أي مستوى البدء في إنشاء واحد. معظم مطوريها ليسوا من ذوي الخبرة ، ولا يكتبون اختبارات لعملهم ، ربما للأسباب التالية:
- لا توجد العديد من المناقشات الجارية حول اختبار الوحدة ، لذلك قد لا يعرفون أن الاختبار ممكن حتى.
- إنهم لا يؤمنون بقيمة كتابة الاختبارات لرموزهم ، أو يعتقدون أنها ستبطئهم.
- إنهم يعتقدون أن الاختبار لمعرفة ما إذا كان المكون الإضافي أو القالب الخاص بهم يعمل في المتصفح كافٍ.
في هذا البرنامج التعليمي ، سوف نتعلم ما هو الاختبار الآلي وأهميته ، ونتعرف على PHPUnit و WP-CLI ، ونتعلم كيفية كتابة اختبار ، وأخيراً ، نقوم بإعداد اختبار آلي مستمر باستخدام Travis CI.
نحن نختار استخدام Travis CI لأنه يوفر تكاملاً سلسًا مع GitHub ؛ لست مضطرًا للذهاب إلى المستودع الخاص بك وإعداد أي اتصال بينهما. وهو مجاني للمستودعات العامة. على عكس منافسيها ، مثل Semaphore CI و GitLab CI و CircleCI ، لا تقدم Travis CI خطة تخزين خاصة مجانية. ومع ذلك ، لا يقدم أي من منافسيها تكاملاً سلسًا مع GitHub كما يفعل.
ما هو الاختبار الآلي؟
وفقًا لـ Wikipedia ، الاختبار الآلي ، أو أتمتة الاختبار ، هو استخدام برنامج خاص (منفصل عن البرنامج قيد الاختبار) للتحكم في تنفيذ الاختبارات ومقارنة النتائج الفعلية بالنتائج المتوقعة. يمكن لأتمتة الاختبار أتمتة بعض المهام المتكررة ولكنها ضرورية في عملية اختبار رسمية موجودة بالفعل ، أو إجراء اختبارات إضافية يصعب إجراؤها يدويًا.
هناك عدة أنواع من الاختبارات. من بين كل شيء ، اختبار الوحدة هو الأكثر شيوعًا. تتحقق اختبارات الوحدة من أن كتلة الكود أو الوظيفة أو طريقة الصنف تؤدي الغرض المقصود منها. سنقوم باختبار الوحدة في هذا البرنامج التعليمي.
يساعد الاختبار الآلي في اكتشاف الأخطاء حتى لا تشق طريقها إلى الإنتاج. لا شك أن المكون الإضافي الذي تم ترميزه واختباره سيستغرق وقتًا أطول حتى يكتمل أكثر من المكون الإضافي الذي لم يتم اختباره. ومع ذلك ، فإن المكون الإضافي الناتج قد يحتوي على أخطاء أقل أو لا يحتوي على أخطاء على الإطلاق.
دعنا نرى مثالًا بسيطًا من العالم الحقيقي يوضح كيف أن اختبارات الوحدة لا تقدر بثمن وما يمكننا استخدامها من أجله.
يحتوي المكون الإضافي الخاص بتوليد العملاء المحتملين على WordPress على فئة OptinThemesRepository
، مع طريقة add()
لإضافة قوالب نماذج الاشتراك الجديدة ، وطريقة get()
لاسترداد قالب نموذج التقيد.
لضمان add()
get()
العمل على النحو المنشود الآن وفي المستقبل ، كتبت الاختبار أدناه.
public function testAddGetMethods() { $kick_optin_form = array( 'name' => 'Kick', 'optin_class' => 'kick', 'optin_type' => 'kick', 'screenshot' => MAILOPTIN_ASSETS_URL . 'img/kick.png' ); // add kick optin theme OptinThemesRepository::add($kick_optin_form); $result = OptinThemesRepository::get('kick'); $this->assertEquals($kick_optin_form, $result); }
إذا بدأ هذا الاختبار بالفشل في المستقبل ، فسأعلم أن هناك مشكلة وسأعرف بالضبط الوظيفة أو طريقة الفصل أو المكان في المكون الإضافي الخاص بي حيث يحدث.
فوائد الاختبار الآلي
الآن بعد أن عرفنا ما هو الاختبار الآلي ، دعنا نرى المزيد من الفوائد.
الكشف المبكر عن الأخطاء
أثناء تطوير البرامج ، يمكنك بسهولة العثور على الأخطاء باستخدام أدوات الاختبار الآلية. يمكن أن يوفر هذا الكثير من الوقت والجهد في تعقب الأخطاء.
جودة برامج أعلى
يمكن للمختبِر الذي يتمتع بخبرة سنوات عديدة أن يرتكب أخطاء عندما يتعين عليه إعداد نفس نصوص الاختبار اليدوي المملة مرارًا وتكرارًا. لا ينتج عن الاختبار الآلي نتائج دقيقة فحسب ، بل يوفر الوقت أيضًا.
تقارير سهلة وقوية
يمكن لأدوات الاختبار الآلي تتبع كل اختبار نصي. يمكن رؤية تنفيذ كل اختبار نصي في السجلات المرئية. يعرض السجل المرئي ، أو التقرير ، عادةً عدد البرامج النصية للاختبار التي تم تنفيذها وحالتها (على سبيل المثال ، تم اجتيازها أو فشلها أو تخطيها) ، والأخطاء التي تم الإبلاغ عنها وتلميحات حول كيفية إصلاح الأخطاء.
قبل أن ننتقل إلى كيفية إعداد الاختبارات وكتابتها ، دعنا ننشئ مكونًا إضافيًا بسيطًا لاستخدامه كدراسة حالة.
بناء البرنامج المساعد WordPress
سنقوم ببناء مكون إضافي بسيط يعرض العلامات الوصفية للتحقق من مشرفي المواقع من Google و Bing في رأس الواجهة الأمامية لـ WordPress. المكون الإضافي مستضاف في حسابي على GitHub.
سيظهر رمز هذا المكون الإضافي أدناه في ملف wp-meta-verify.php
.
<?php class WP_Meta_Verify { public function __construct() { add_action('wp_head', \[$this, 'header_code']); } public function header_code() { $google_code = get_option('wpmv_google_code'); $bing_code = get_option('wpmv_google_code'); echo $this->google_site_verification($google_code); echo $this->bing_site_verification($bing_code); } public function google_site_verification($code) { return "<meta name=\"google-site-verification\" content=\"$code\">"; } public function bing_site_verification($code) { return "<meta name=\"msvalidate.01\" content=\"$code\">"; } } new WP_Meta_Verify();
قد تلاحظ أننا لم نقم بتضمين صفحة إعدادات في المكون الإضافي ، حيث ستحفظ عادةً رمز التحقق من Google و Bing فيه. لقد فعلت ذلك عن قصد لإبقاء الأمر بسيطًا ولتركيز انتباهنا على ما هو أكثر أهمية. ومع ذلك ، get_option('wpmv_google_code')
و get_option('wpmv_bing_code')
أن هناك صفحة إعدادات ، ويستردون رموز التحقق من هناك.
وحدة اختبار البرنامج المساعد WordPress
PHPUnit هي أداة اختبار فعلية لـ PHP ، بينما WP-CLI هي واجهة سطر الأوامر الرسمية لـ WordPress.
قبل WP-CLI ، كان إعداد اختبار PHPUnit لملحقات WordPress أمرًا مزعجًا. WP-CLI لديه دليل رائع لإعداده ؛ ومع ذلك ، سنستمر في تجاوز الخطوات هنا.
قم بتثبيت PHPUnit
لتثبيت PHPUnit ، قم بتشغيل الأوامر التالية.
composer global require phpunit/phpunit:5.*
ملاحظة: نقوم بتثبيت 5.x
بشكل صريح لأن هذا ما يدعمه WordPress عندما تقوم بتشغيل PHP 7 أو أعلى ، وهو ما لدي على جهازي. قم بتثبيت PHPUnit 4.8 إذا كنت تستخدم PHP الإصدار 5.
قم بتشغيل phpunit --version
للتأكد من تثبيته.
قم بتثبيت WP-CLI
لتثبيت WP-CLI ، قم بتشغيل الأوامر التالية.
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar chmod +x wp-cli.phar sudo mv wp-cli.phar /usr/local/bin/wp
قم بتشغيل wp --info
لتأكيد التثبيت.
بعد تثبيت PHPUnit و WP-CLI ، سنستخدم الأخير لإعداد اختبار الوحدة للمكون الإضافي.
قم بإعداد اختبار وحدة البرنامج المساعد
قم بتغيير دليل المحطة الطرفية إلى جذر تثبيت WordPress الخاص بك ، وقم بتشغيل الأمر أدناه لإنشاء ملفات اختبار البرنامج المساعد.
wp scaffold plugin-tests wp-meta-verify
فيما يلي الشكل الذي ستبدو عليه بنية البرنامج المساعد بعد أن ينشئ الأمر أعلاه ملفات الاختبار.
|-bin/ |----install-wp-tests.sh |-tests/ |----bootstrap.php |----test-sample.php |-.travis.yml |-phpcs.xml.dist |-phpunit.xml.dist |-wp-meta-verify.php
ملاحظة: بشكل افتراضي ، يقوم الأمر wp scaffold plugin-tests
بإنشاء ملف تكوين Travis CI. يمكنك تحديد علامة --ci
لإنشاء ملف تكوين لخدمة CI التي تستخدمها ، مثل: wp scaffold plugin-tests --c gitlab
. في وقت كتابة هذا التقرير ، تم دعم Travis CI و CircleCI و GitLab CI فقط.
قم بتغيير دليل المحطة الطرفية إلى دليل البرنامج المساعد الخاص بك ، وقم بتشغيل نص التثبيت:
cd path-to-wordpress-plugin
bin/install-wp-tests.sh wordpress_test root '' localhost latest
إذا كنت مثلي ، فإن اسم مستخدم MySQL ليس root
، وكلمة المرور ليست فارغة. على سبيل المثال ، افترض أن اسم المستخدم هو homestead
وكلمة المرور secret
. يمكنك تشغيل نص التثبيت كما يلي:
bin/install-wp-tests.sh wordpress_test homestead 'secret' localhost latest
قم بتشغيل الأمر phpunit
لتشغيل الاختبار الافتراضي في tests/test-sample.php
.
اكتب اختبارات البرنامج المساعد
قم بإنشاء ملف test-wp-meta-verify.php
في مجلد tests
. سيحتوي على اختبارات البرنامج المساعد الخاصة بنا مع فئة setUp
التالية.
<?php class WP_Meta_VerifyTest extends WP_UnitTestCase { public function setUp() { parent::setUp(); $this->class_instance = new WP_Meta_Verify(); } public function test_google_site_verification() { } public function test_bing_site_verification() { } }
من الجدير بالذكر أنه لكي يتم اعتبار الطريقة اختبار وحدة ، يجب أن تكون مسبوقة test
. من أفضل الممارسات إضافة لاحقة Test
لكل فئة اختبار ، على الرغم من أنها غير مطلوبة. راجع WP_Meta_VerifyTest
.
محتار حول ما يفعله setUp()
؟ فقط اعلم أن PHPUnit تقوم بتشغيلها مرة واحدة قبل كل طريقة اختبار (وفي حالات جديدة) لفئة حالة الاختبار. يوجد أيضًا tearDown()
، ولكن يتم تشغيله بعد كل طريقة اختبار. هناك أيضًا setUpBeforeClass()
و tearDownAfterClass()
، والتي تعمل قبل وبعد كل حالة اختبار ، على التوالي. حالة الاختبار هي في الأساس فئة تحتوي على عدد من طرق الاختبار. راجع دليل WordPress ووثائق PHPUnit لمزيد من المعلومات.
من الفصل أعلاه ، من الواضح أننا سنكتب اختبارات لطرق google_site_verification
و bing_site_verification
الخاصة بنا.
public function test_google_site_verification() { $meta_tag = $this->class_instance->google_site_verification('B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g'); $expected = '<meta name="google-site-verification" content="B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g">'; $this->assertEquals($expected, $meta_tag); }
public function test_bing_site_verification() { $meta_tag = $this->class_instance->bing_site_verification('B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g'); $expected = '<meta name="msvalidate.01" content="B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g">'; $this->assertEquals($expected, $meta_tag); }
بشكل أساسي ، ستضمن الاختبارات أن كلا الطريقتين تعيد العلامة الوصفية الصحيحة عندما يتم تمرير رموز التحقق من مشرف موقع Google و Bing إليهما كوسيطات.
قم بتشغيل phpunit
، وسترى إخراجًا مشابهًا للقطة الشاشة أدناه.
اختبار آلي مستمر مع ترافيس سي آي
Travis CI هي خدمة تكامل مستمرة موزعة ومُستضافة تُستخدم لبناء واختبار مشاريع البرامج المستضافة على GitHub.
لاستخدام Travis CI ، يجب علينا نشر المكون الإضافي الخاص بنا على GitHub. انطلق وافعل ذلك الآن. لا تتردد في الرجوع إلى خاصتي.
بفضل WP-CLI ، قمنا بالفعل بإعداده في المكون الإضافي الخاص بنا ، من خلال ملف .travis.yml
.
أود أن أذكر أنني لا ألتزم بمعايير ترميز WordPress ، بل بتوصيات معايير PHP ، وتتطلب الإضافات الخاصة بي PHP 5.4 على الأقل. لكي لا تفشل بنياتي ، كان علي استبدال المصفوفة الخاصة بهم بالمصفوفة التالية في ملف .travis.yml
.
matrix: include: - php: 7.1 env: WP_VERSION=latest - php: 7.0 env: WP_VERSION=latest - php: 5.6 env: WP_VERSION=latest - php: 5.6 env: WP_VERSION=trunk - php: 5.5 env: WP_VERSION=latest - php: 5.4 env: WP_VERSION=latest
توجه إلى Travis CI وقم بتسجيل الدخول باستخدام حساب GitHub الخاص بك. اتبع الدليل الذي يظهر على الشاشة لإضافة مستودع GitHub الخاص بك.
بعد مزامنة الحساب مع GitHub ، قم بالتمرير إلى مستودع المكون الإضافي الخاص بك وقم بتنشيطه.
في المرة التالية التي تقوم فيها بتغيير التعليمات البرمجية والدفع إلى GitHub ، سيتم تشغيل بناء على Travis CI.
لقد أتاحت نتيجة بناء ناجحة من أجل متعة المشاهدة.
تغليف
ليس سراً أن الكثير من المطورين ، وليس فقط مطوري WordPress ، لا يكتبون اختبارات لمشاريعهم لأنهم لا يعرفون عنها. حتى بعض ذوي الخبرة والمتقدمين بيننا لا يبدو أنهم يعتبرون ذلك مضيعة للوقت.
من المؤكد أن إعداد الاختبار الآلي يمكن أن يكون مملاً ويستغرق وقتًا طويلاً. ومع ذلك ، فهو استثمار يضمن تسلل عدد قليل من الأخطاء أو عدم تسللها إلى برنامجك ، مما يوفر لك الوقت والموارد (بما في ذلك المالية) التي قد تكلفك الأخطاء في برنامجك.
اكتب دائمًا اختبارًا قبل تنفيذ الميزة ، حتى لا تنسى أو تشعر بالكسل للقيام بذلك بعد تطبيق الميزة.
أتمنى أن تدرك الآن أهمية كتابة الاختبارات وكيفية البدء في كتابة اختبار لمكوِّن WordPress الإضافي الخاص بك.
إذا كان لديك أي أسئلة أو تعليقات ، فيرجى إبلاغي بذلك في قسم التعليقات.