دليل:قائمة تحقق ما قبل الالتزام

هذه محاولة لصياغة قائمة تحقق بغرض الاستخدام قبل التزام نسخة من برامج. يكرر بعض مما هو مذكور هنا ما ذكر في أعراف البرمجة إلا أنه في صيغة قائمة تحقق سريعة. قائمة التحقق هذه مشابهة لقائمة The Checklist Manifesto. قد يبدو بعض مما ذكر هنا سخيفا (مثل أن تطرح على طبيب سؤال «هل غسلت يديك؟») إلا أن الغرض منها تجنب المشاكل التي قد تغيب عن البعض.

Back-end (PHP)

• هل جرى كودك البرمجي دون أي مشاكل بموجب ‎E_STRICT؟
• هل تسبب كودك البرمجي في تعطيل أي من اختبارات الوحدات؟ انظر Manual:PHP unit testing .
• هل اختبرت كافة نقاط الخروج من كودك البرمجي؟
• هل استخدمت علامات الجدولة بدلا من المسافات في محاذاة النص؟
• هل أزلت كود تصويب الأخطاء الإضافي الذي يحتوي على تعليقات؟ (مثال #var_dump( $array ); و/أو #die();)
• لو أنتجت سمة جديدة، هل وثّقت متغيرات السمة وما ينتج عنها مستخدما Doxygen؟
• هل أنشأت معرفّات لا تستخدم camelCase (أي استخدام الشرطة التحتية)؟
• هل اختبرت كل حالة استثناء؟
• لو كانت لديك نقاط عودة متعددة، هل اختبرتها جميعًا؟
• هل كل رسالة أنشأتها موجودة في languages/i18n/en.json، ويوجد لتلك الرسائل توثيق في languages/i18n/qqq.json؟
• هل جرى التحقق من كل استخدام لكل من fopen() أو fread() وخلافه بحثًا عن أخطاء أو مشاكل؟
• هل تستخدم وسوم t أو b لأغراض fopen() كي تحرص على توافق إصدار الويندوز؟
• هل استخدمت وظائف الإخراج الملائمة؟ يجب تجنب استخدام echo دائمًا.
• هل استخدمت وظائف الإنهاء الملائمة؟ يجب تجنب استخدام exit دائمًا.
• حيثما كان ذلك مطلوبًا، هل استخدمت دوال حزم ميديايويكي بدلا من مكافئاتها المستخدمة في بي إتش بي؟
  • wfIniGetBool() - بدلًا من ini_get للحصول على معلمات بوليانية/منطقية.
  • للوصول إلى قاعدة البيانات، طالع Manual:Database access#Database Abstraction Layer .
• لو أضفت اختبار جديد إلى parserTests.txt، هل تمنحه اسم جديد؟
• لو أضفت رابط جديد، هل وثقته ؟

الاختبار

حين إضافة السمات، من الأهمية بمكان التحقق من أنك لم تعطّل الوظائف القائمة. لدينا ثلاثة أنواع من الاختبارات التي يجوز أن يستلزمها الأمر منك أن تكتبها لكود النهاية الخلفية:

• Parser tests - اختبار خرج المعرب اللغوي لنصوص الويكي (طالع tests/parser/parserTests.php). حاول تشغيل php tests/parser/parserTests.php --quick --quiet كي ترى كيف تعمل. من الناحية النظرية، يجب أن يعمل كل شيء. يمكنك إضافة اختبارات جديدة أو تصويب القائمة منها عن طريق تعديل tests/parser/parserTests.txt.
• اختبارات الوحدات (PHPUnit) - موجودة في مجلد tests/phpunit. تشغّل في العادة عن طريق أمر composer phpunit:entrypoint الذي يبدأ من مجلد ميدياويكي. تشمل هذه الاختبارات أيضًا اختبارات المعرب اللغوي الأصلية، إلا أن parserTests.php يعمل في الغالب أسرع. طالع Manual:PHP unit testing لمزيد من المعلومات عن كيفية إعداد وحدة بي إتش بي وتفاصيل أخرى عن كيفية استخدامها داخل ميدياويكي.
• Selenium - الاختبارات في المجلد tests/selenium.

على أي حال، لو لم تستطع كتابة اختبار تلقائي، أجري الاختبار يدويًا. لو تسببت في حدوث عطل عدة مرات، سيشعر الآخرين بالضيق تجاهك.

Front-end

• هل اختبرته في متصفح فعلي؟ قد ينتج عن أتفه التغييرات تعطيل أمور ليست بادية للعيان. افتح هذا المتصفح وتنقل بين الصفحات وعدّل شيء ما أو سجل الدخول أو أضف صفحة إلى قائمة مراقبتك.
• هل تسبب كودك البرمجي في تعطيل أي من اختبارات الوحدات؟ انظر Manual:JavaScript unit testing
• هل سيعمل على الأقل في المتصفحات التي ندعمها للحصول على سلاسة عمل من المستوى الأول (طالع التوافق#المتصفحات )؟
• هل توجد أي أمور عمومية مفترضة خلاف jQuery أو mediaWiki؟ يجب ألا يوجد أي منها، (ولا $ كذلك)

الاختبار الآلي

يشغّل Jenkins بعض الاختبارات على أغلب المستودعات حينما ترسل التغييرات إلى Gerrit وتحصل على الاعتماد. يجب عليك أن تشغّل هذه الاختبارات محليًا قبل التزام رقعة تصويب برمجية. تنفّذ عدة امتدادات المعيار القياسي الإدماج المستمر/نقاط الإدخال وبالتالي يمكنك تشغيل npm test وgrunt test قبل الالتزام.

في الواقع، أنت لن تختبر دائمًا كل تغيير تجريه يدويًا. يعتمد الأمر على مقدار العطل وما إذا كانت ثمة اختبارات وحدات جيدة يمكن إجرائها على ما نفّذ من تغييرات.

• هل يتولى التصديق (أو هل شغلته على الأقل) لكل من JSHint أو JSLint؟ (check recommended settings )
• اختبار الوحدات (QUnit): موجود في مجلد tests/qunit. عادة ما يتم تشغيلها من المتصفح عن طريق Special:JavaScriptTest/qunit. اقرأ Manual:JavaScript unit testing لمزيد من المعلومات عن كيفية تمكينها وكيفية عملها والخيارات المختلفة المتاحة.