Manual:Pre-commit checklist/ar

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

Back-end (PHP)

 * هل جرى كودك البرمجي دون أي مشاكل بموجب ‎ ؟
 * هل تسبب كودك البرمجي في تعطيل أي من اختبارات الوحدات؟ انظر.
 * هل اختبرت كافة نقاط الخروج من كودك البرمجي؟
 * هل استخدمت علامات الجدولة بدلا من المسافات في محاذاة النص؟
 * هل أزلت كود تصويب الأخطاء الإضافي الذي يحتوي على تعليقات؟ (e.g.  and/or  )
 * لو أنتجت سمة جديدة، هل وثّقت متغيرات السمة وما ينتج عنها مستخدما Doxygen؟
 * هل أنشأت معرفّات لا تستخدم camelCase (أي استخدام الشرطة التحتية)؟
 * هل اختبرت كل حالة استثناء؟
 * لو كانت لديك نقاط عودة متعددة، هل اختبرتها جميعًا؟
 * هل كل رسالة أنشأتها موجودة في ، ويوجد لتلك الرسائل توثيق في  ؟
 * Is each use of,  , etc. checked for errors or problems?
 * Did you use  or   flags for   to ensure Windows compatibility?
 * Have you used the proper output functions?   should almost never be used.
 * Have you used the proper termination functions?   should almost never be used.
 * حيثما كان ذلك مطلوبًا، هل استخدمت دوال حزم ميديايويكي بدلا من مكافئاتها المستخدمة في بي إتش بي؟
 * instead of  to get boolean params.
 * For database access, see Manual:Database_access.
 * If you added a new test to, did you give it a new name?
 * If you added a new hook, did you document it?

الاختبار
When adding features, it's vital to verify you didn't break existing functionality. We have three kinds of tests you can be required to write for backend code:


 * Parser tests: Test the parser output for wikitext (see ). Try running   to see how those work.  Everything should pass, in theory.  You can add new tests or fix existing ones by editing.
 * Unit tests (PHPUnit): Located in the  directory. They are typically run through the   script invoked from the aforementioned directory. These tests also include ordinary parser tests, though   probably works faster. Read Manual:PHP unit testing for more information about how to setup PHPUnit and further details on how it is used inside MediaWiki.
 * Selenium: tests are in directory.

Anyway, if you can't write an automatic test, do manual testing. If you cause breakage too often, people will get annoyed at you.

Front-end

 * Tested in an actual browser? The smallest changes could break things that aren't obvious. Kick that browser open, navigate around, perhaps make an edit, log-in, add a page to your watchlist.
 * Did your code break any of the unit tests? See Manual:JavaScript unit testing
 * Will it work at least in the browsers we support for A-grade functionality (check Compatibility)?
 * Are there any implied globals other than  or  ? There should not be, (not   either)

الاختبار الآلي
Jenkins runs some tests on most repositories when changes are submitted to gerrit and approved. You should run these tests locally before committing a patch. Many extensions implement the standard Continuous integration/Entry points and so you can run npm test and grunt test before committing.

Realistically, you won't always manually test every change. It depends on how big failure can be and whether there are good unit tests for the change.


 * Does it validate (or did you at least run it through) JSHint or JSLint ? (check recommended settings)
 * Unit tests (QUnit): Located in the  directory. They are typically run from the browser via . Read Manual:JavaScript unit testing for more information on how to enable it, how it works and the various options that are available.