Manual:Pre-commit checklist: Difference between revisions
preparation for translation |
preparation for translation Tag: Reverted |
||
Line 46: | Line 46: | ||
</translate> |
</translate> |
||
* <translate><!--T:24--> Tested in an actual browser? The smallest changes could break things that aren't obvious.</translate> <translate><!--T:25--> Kick that browser open, navigate around, perhaps make an edit, log-in, add a page to your watchlist.</translate> |
* <translate><!--T:24--> Tested in an actual browser? The smallest changes could break things that aren't obvious.</translate> <translate><!--T:25--> Kick that browser open, navigate around, perhaps make an edit, log-in, add a page to your watchlist.</translate> |
||
* Did your code break any of the unit tests? See |
* <translate>Did your code break any of the unit tests? See {{ll|Manual:JavaScript unit testing|Manual:JavaScript unit testing}}</translate> |
||
* Will it work at least in the browsers we support for A-grade functionality (check [[Compatibility#Browsers]])? |
* <translate>Will it work at least in the browsers we support for A-grade functionality (check <tvar name=1>[[Compatibility#Browsers]]</tvar>)?</translate> |
||
* Are there any implied globals other than <code>jQuery</code> or <code>mediaWiki</code>? There should not be, (not <code>$</code> either) |
* <translate>Are there any implied globals other than <tvar name=1><code>jQuery</code></tvar> or <tvar name=@><code>mediaWiki</code></tvar>?</translate> <translate>There should not be, (not <tvar name=1><code>$</code></tvar> either)</translate> |
||
<translate> |
<translate> |
||
== Automatic testing == <!--T:8--> |
== Automatic testing == <!--T:8--> |
||
</translate> |
</translate> |
Revision as of 16:31, 11 February 2024
This is an attempt to create a checklist to use before making a commit. Some of this duplicates what is in the coding conventions, but is in the form of quick checks. This checklist is in the same vein as The Checklist Manifesto. Some of these may seem silly (like asking a doctor “did you wash your hands?”) but they're meant to avoid problems that may be overlooked.
Back-end (PHP)
- Did your code run without errors under
E_STRICT
?[1] - Did your code break any of the unit tests? See Manual:PHP unit testing .
- Have you tested all exit points from your code?
- Did you use tabs instead of spaces to indent?
- Did you remove extraneous, commented-out debug code? (e.g.
#var_dump( $array );
and/or#die();
) - If you've created a new function, did you document the function parameters and what it returns using Doxygen?
- Have you created any identifiers that didn't use camelCase (i.e. underscores)?
- Is every exception tested?
- If you have multiple return points, are they tested?
- Does each message you've created exist in
languages/i18n/en.json
, have message documentation inlanguages/i18n/qqq.json
? - Is each use of
fopen()
,fread()
, etc. checked for errors or problems? - Did you use
t
orb
flags forfopen()
to ensure Windows compatibility? - Have you used the proper output functions?
echo
should almost never be used. - Have you used the proper termination functions? {{<tvar name=1>ll|Manual:Writing_testable_PHP_code#Do_not_use_exit.28.29</tvar>|
exit
should almost never be used}}. - Where appropriate, have you used the MediaWiki wrapper functions instead of their PHP equivalents?
wfIniGetBool()
instead ofini_get
to get boolean params.- For database access, see Manual:Database access#Database Abstraction Layer .
- If you added a new test to
parserTests.txt
, did you give it a new name? - If you added a new hook, did you document it ?
Testing
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
tests/parser/parserTests.php
). Try runningphp tests/parser/parserTests.php --quick --quiet
to see how those work. Everything should pass, in theory. You can add new tests or fix existing ones by editingtests/parser/parserTests.txt
. - Unit tests (PHPUnit) - Located in the
tests/phpunit
directory. They are typically run through thecomposer phpunit:entrypoint
command invoked from the MediaWiki directory. These tests also include ordinary parser tests, thoughparserTests.php
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
tests/selenium
.
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#Browsers)?
- Are there any implied globals other than
jQuery
ormediaWiki
? There should not be, (not$
either)
Automatic testing
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
tests/qunit
directory. They are typically run from the browser via Special:JavaScriptTest/qunit. Read Manual:JavaScript unit testing for more information on how to enable it, how it works and the various options that are available.
References
- ↑ Put
error_reporting(-1);
in the entry file. See also Manual:How to debug .