Liste de vérifications pré-commit

This page is a translated version of the page Manual:Pre-commit checklist and the translation is 48% complete.
Other languages:

Ceci est une tentative de création d'une liste de choses à vérifier avant de valider des modifications. Certains de ces points font doublon avec ce qu'il y a dans conventions de codage, mais sont sous la forme de vérifications rapides. Cette checklist est dans le même genre que The Checklist Manifesto. Certaines de ces choses semble évidentes (comme si l'on demandait à un médecin "avez-vous lavé vos mains ?"), mais sont là afin d'éviter des problèmes qui pourraient être oubliés.


Dorsal (PHP)

  • Did your code run without errors under E_STRICT?[1]
  • Votre code a-t-il échoué à un des tests unitaires ? Voir Tests unitaires PHP .
  • Avez-vous testé tous les points de sorties de votre code ?
  • Avez-vous pour l'indentation utilisé des tabulations au lieu d'espaces ?
  • 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 in languages/i18n/qqq.json?
  • Is each use of fopen(), fread(), etc. checked for errors or problems?
  • Did you use t or b flags for fopen() to ensure Windows compatibility?
  • Have you used the proper output functions? echo should almost never be used.
  • Have you used the proper termination functions? exit should almost never be used.
  • Where appropriate, have you used the MediaWiki wrapper functions instead of their PHP equivalents?
  • 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?

Test

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 running php 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 editing tests/parser/parserTests.txt.
  • Unit tests (PHPUnit): Located in the tests/phpunit directory. They are typically run through the phpunit.php script invoked from the aforementioned directory. These tests also include ordinary parser tests, though parserTests.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.

Frontal

  • 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 or mediaWiki? There should not be, (not $ either)

Test automatique

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.


Références

  1. Put error_reporting(-1); in the entry file. See also Comment déboguer .