Это попытка создать контрольный список, который можно использовать перед фиксацией изменений. Некоторые из них дублируют то, что есть в соглашения о кодировании, но в виде быстрых проверок. Этот список проверки соответствует тому же содержанию, что и Манифест самопроверки. Некоторые из них могут показаться глупо (например, спросить у врача: "мыли ли вы руки?"), но они предназначены для того, чтобы избежать проблем, которые могут быть не замечены.

Бэкенд (PHP)

• Запускается ли ваш код без ошибок E_STRICT?^[1]
• Ваш код нарушил какие-либо испытания? Смотрите Manual:PHP unit testing .
• Вы проверили все точки выходы из своего кода?
• Вы использовали табуляцию вместо пробелов для отступа?
• Удалили ли вы лишние, закомментированный код отладки? (Например, #var_dump( $array ); и/или #die();)
• Если вы создали новую функцию, вы задокументировали функции параметры и то, что она возвращает, используя Doxygen?
• Создавали ли вы какие-либо идентификаторы, в которых не использовался camelCase (т. е. подчеркивание)?
• Все исключения проверены?
• Если у вас есть несколько точек возврата, они проверены?
• Существует ли каждое сообщение которое вы создали в languages/i18n/en.json, имеет ли документацию сообщения в languages/i18n/qqq.json?
• Каждое использование fopen(), fread(), и т.д. проверяется на ошибки или проблемы?
• Вы использовали флаги t или b за fopen() для обеспечения совместимости Windows?
• Вы использовали правильные функции выхода? echo почти никогда не был использован.
• Вы использовали правильные функции терминации? exit почти никогда не следует использовать.
• При необходимости, вы использовали функции обертывания MediaWiki вместо их эквивалентов PHP?
  • wfIniGetBool() - вместо ini_get получать булевые параметры.
  • Для доступа к базе данных, смотрите Руководство:Доступ к базе данных#Уровень_абстракции_базы_данных .
• Если вы добавили новое тестирование к parserTests.txt, вы дали ему новое имя?
• Если вы добавили новый хук, вы задокументировали его ?

Фронтенд

• Тестирования проведены в актуальном веб-обозревателе? Даже удаление одной строчки кода, может разрушить неочевидные вещи. Откройте браузер, проходите по нему, возможно, редактируйте, входите, добавьте страницу в свой список наблюдений.
• Ваш код нарушил какие-либо испытания? Посетите Manual:JavaScript unit testing
• Будет ли он работать хотя бы в тех браузерах, которые мы поддерживаем для функциональности A-класса (проверьте Совместимость#Браузеры )?
• Есть ли какие-либо подразумеваемые глобальные значения, кроме jQuery или mediaWiki? Не должно быть, (и $ также)

Автоматическое тестирование

Jenkins выполняет несколько тестирований в большинстве репозиториев, когда изменения передаются Gerrit , и фиксируются. Вы должны провести эти тестирования на локальном уровне, прежде чем фиксировать патч. Многие расширения реализуют стандартный Continuous integration/Entry points и поэтому, вы можете выполнить npm test и grunt test перед фиксацией изменений.

В реальности вы не всегда сможете вручную тестировать каждое изменение. Это зависит от того, насколько серьезным может быть отказ и есть ли хорошие модульные тесты для изменения.

• Валидирует ли он (или, вы хотя бы прошли через) JSHint или JSLint? (check recommended settings )
• Модульные тестирования (QUnit): Расположенный в директории tests/qunit. Они обычно запускаются из браузера, через Special:JavaScriptTest/qunit. См. также Manual:JavaScript unit testing для получения большей информации о том, как включить его, как он работает и различные варианты, которые доступны.

Примечания