Manual:PHP unit testing/Writing unit tests/fr

Le manuel de tests unitaires PHP fournit de bonnes informations quant à la compréhension et le développement des tests unitaires. Faites particulièrement attention aux sections concernant l'écriture et l'organisation des tests.



Développer les meilleures pratiques
Les développeurs nouveaux pour les tests unitaires de MediaWiki doivent utiliser comme point d'entrée – il contient des commentaires utiles facilitant le processus d'apprentissage de l'écriture des tests unitaires.

Une autre ressource sont les transparents de la discussion sur les Meilleures pratiques de  PHPUnit que Sebastian Bergmann a donnée à l'OSCON 2010.

Les développeurs doivent éviter d'inventer de nouvelles conventions, ou d'importer les conventions d'autres environnements; l'utilisation des conventions PHPUnit déja bien établies sert à ce que les tests MediaWiki soient à la fois utiles et utilisables.

Les tests unitaires doivent suivre l' Ensemble des règles des tests unitaires de Michael Feathers.



Ecrire du code testable
MediaWiki n'a pas été écrit avec l'objectif d'être testable. Il utilise des variables globales partout et des méthodes statiques à de nombreux endroits. C'est un héritage que nous devons accepter, mais n'introduisez pas ces éléments dans le nouveau code et essayez de modifier en avançant.

Une bonne ressource peut être le Guide de la testabilité de Miško Hevery. (Miško Hevery est l'un [?] des coachs Agile de Google).



Conventions des tests
Le nom du fichier doit se terminer par. Utilisez comme point d'entrée.



setUp et tearDown

 * Doivent être des fonctions de type.
 * tearDown doit être dans l'ordre inverse de setUp.
 * setUp commence par appeler son parent.
 * tearDown se termine en appelant son parent.



Fonctions d'assertions

 * Doivent être des fonctions de type.
 * Le nom de la fonction doit être de la forme lowerCamelCase où la première lettre est en bas de casse, et commencer par le mot  ; par exemple,.
 * Partout où cela est possible, faire référence à la méthode la plus importante à tester; par exemple, est testé dans.



Sources de données

 * Doivent être des fonctions de type.
 * Le nom du fournisseur de données doit être de la forme lowerCamelCase où la première lettre est en bas de casse, et commencer par le mot  ; par exemple,.
 * Ne pas instancier les services MediaWiki, car les fournisseurs de données sont appelés avant . Par exemple au lieu de, utiliser   pour éviter de créer un.



Raconter une histoire
Les sorties des tests doivent raconter une histoire. The  output format is a good way to view this story: a test suite execution is displayed as a set of statements about the test classes, along with whether or not they have passed. The statements (unless customized) are the test method names with corrected capitalization and spacing.

The  annotation can be used to customize the message that is displayed. It is not currently used in the MediaWiki codebase.

See "Other Uses for Tests" for more information.



Nombre d'assertions
Chaque test ne doit vérifier qu'une seule assertion, sauf s'il existe une bonne raison (regrouper les tests longs).



Regrouper les tests
PHPUnit permet de regrouper les tests dans des groupes arbitraires. Groups of tests can be selected for execution or excluded from execution when the test suite is run (see the @group annotation, The Command-Line Test Runner and XML Configuration File documentation in the PHPUnit manual for additional details.)

To add a test (or class) to a group, use the  annotation in the docblock preceding the code. Par exemple :

Plusieurs groupes fonctionnels sont actuellement utilisés dans les tests unitaires MediaWiki :


 * API - Tests that exercise the MediaWiki API.
 * Broken - Put broken tests into group Broken. Tests in this group will not be run (as is configured in ).
 * Database - Tests that require database connectivity should be put into group Database. NOTE: this causes temporary tables to be overlayed over the real wiki database, so test cases can perform database operations without changing the actual wiki.
 * Destructive - Tests that alter or destroy data should be put into group Destructive.
 * Search - Tests that use MediaWiki's built-in search put into group Search.
 * SeleniumFramework - Tests that require SeleniumFramework to be installed should be put in group SeleniumFramework.
 * Stub - Put test stubs into group Stub. Tests in this group will not be run (as is configured in ).
 * sqlite - Tests that use SQLite should be put into group sqlite.
 * Upload - Tests that upload files should be put into group Upload.
 * Utility - Currently unused by any test. Tests in this group will be not be run (as is configured in ).

En plus, vous pouvez regrouper les tests en fonction de l'équipe de développement :


 * Fundraising
 * EditorEngagement
 * Internationalization
 * etc.

To test only a particular group, use the  flag from the command line:

php phpunit.php --group Search

or if you use the Makefile in core/tests/phpunit:

make FLAGS="--group Search" target

where target can be phpunit, safe, etc.

Couverture
The PHPUnit documentation has a chapter about coverage. There is a coverage report for mediawiki core generated twice a day. As the forceCoversAnnotation option should be in effect the test should be marked with @covers annotations to express which parts of the code the test actually checks (as opposed to code that is just run but whose results are never tested for with assertions).

Note that  requires fully-qualified class names (unlike  annotations such as  ).

Les bases de données
When testing database-dependent code, you should put your test case in the Database group (see above). That tells MediaWikiTestCase to setup a  database connection for you to use in. Normally, this uses a separate temporary database, with certain limited data prefilled by, including a 'UTSysop' user and a 'UTPage' title. A test case can add additional data to the database by overriding  (which by default does nothing).

Si vous souhaitez utiliser une autre table de base de données (disons, pour votre extension), cela n'est pas possible par défaut pour les tests. Pour ajouter la table à la base de données temporaire construite durant les tests, vous devez l'ajouter à, par exemple :

Néanmoins il est à noter que seul le schéma des tables est recopié à partir de votre base de données actuelle et non pas les données qu'elles contiennent.

Vous pouvez directement tester le contenu actuel de la base de données avec.

Voici quelques exemples d'extensions que vous pouvez regarder à titre de référence.


 * - de
 * - de

Tests that are not in the Database group still run against a temporary cloned database (even if they ignore and instead use e.g.  directly); however, this database is only set up once for the whole test run, and not reset between test runs. Les tests doivent éviter de s'appuyer sur cette fonctionnalité de sécurité autant que possible.



Scripts de maintenance
Test cases for should inherit from, to handle the different output channels used by maintenance scripts.

The base test case method will instantiate your   object for you, if you specify the class to construct by providing the mandatory  in your subclass:

In the unlikely event that you want to do something special to instantiate the class under test, you can override the method, but hopefully this isn't needed.

Par défaut, la sortie des scripts de maintenance sera supprimée et ignorée. Si vous souhaitez tester la sortie (et c'est une bonne idée), utilisez un code tel que :

Cas d'échec
Habituellement le code de test ne doit pas exécuter mais utiliser la méthode   de phpunit :

Ceci devrait apparaître comme un incident dans le résumé de test plutôt que de bloquer toute la suite de tests.