Liste des vérifications avant validation
Ceci est une tentative de création d'une liste de points à vérifier avant de valider des modifications. Certains de ces points font doublon avec ce qu'il y a dans les conventions de codage, mais sont présentés sous forme de vérifications rapides. Cette liste de contrôle est du même style que The Checklist Manifesto. Certaines de ces choses semblent évidentes (comme si on demandait à un médecin "Avez-vous lavé vos mains ?"), mais sont là afin d'éviter des problèmes qui pourraient avoir été oubliés.
Côté serveur dorsal (PHP)
- Votre code s'exécute-t-il sans erreur sous
E_STRICT
?[1] - Votre code a-t-il échoué dans un test unitaire ? Voir Tests unitaires PHP .
- Avez-vous testé tous les points de sortie de votre code ?
- Avez-vous pour l'indentation utilisé des tabulations au lieu d'espaces ?
- Avez-vous supprimé du code de débogage supplémentaire, ou bien en avez-vous mis en commentaire ? (e.g.
#var_dump( $array );
and/or#die();
) - Si vous avez créé une nouvelle fonction, ses paramètres sont-ils documentés ainsi que les valeurs retournées, en utilisant Doxygen ?
- Avez-vous créé des identifiants qui n'ont pas le format camelCase (par exemple avec des caractères souligné '_') ?
- Chaque exception a-t-elle été testée ?
- Si vous avez plusieurs points de retour, ont-ils été testés ?
- Est-ce que chaque message que vous avez créé existe dans
languages/i18n/en.json
, et est-il documenté danslanguages/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?
exit
should almost never be used. - A quels endroits avez vous utilisé les fonctions spécifiques de MédiaWiki à la place de leur équivalents PHP ?
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 ?
Tests
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 Tests unitaires PHP 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.
Côté frontal utilisateur
- Les tests ont ils été faits avec un navigateur à jour ? Même des modifications anodines peuvent casser des éléments pas évidents. Laissez ce navigateur ouvert, naviguez un peu sur les pages, faites une modification, connectez-vous, ajoutez une page à votre liste de suivi.
- Did your code break any of the unit tests? See Tests unitaires JavaScript
- 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)
Tests automatiques
Jenkins runs some tests on most repositories when changes are submitted to Gerrit and approved. Ces tests doivent être exécutés localement avant de valider une correction avec commit. Many extensions implement the standard Intégration continue/Points d'entrée and so you can run npm test and grunt test before committing.
En pratique, vous n'allez pas toujours tester manuellement chaque modification. Cela dépend de l'importance de la faute et s'il existe des tests unitaires adaptés à la modification.
- 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 Tests unitaires JavaScript for more information on how to enable it, how it works and the various options that are available.
Références
- ↑ Mettre
error_reporting(-1);
dans le fichier d'entrée. Voir aussi Comment déboguer .