Manual:PHP unit testing/Writing unit tests/fr



Conseils généraux
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. Le format de sortie  est une bonne manière de visualiser cette histoire : une exécution d'une suite de tests est affichée comme un ensemble de déclarations à propos des classes de tests, avec l'indication pour chacune d'elle si elle a réussi ou pas. Les déclarations (à moins d'être adaptées) sont les noms des méthodes de test avec la casse et les espaces corrigés.

L'annotation  peut être utilisée pour adapter le message à afficher. Actuellement, ceci n'est pas utilisé dans la base de code MediaWiki.

Voir les Autres utilisations pour les tests pour plus d'informations.



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

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.



Spécifique à MediaWiki


Regrouper les tests
PHPUnit permet de regrouper les tests dans des groupes arbitraires. Les groupes de tests peuvent être sélectionnés pour être exécutés, ou exclus de l'exécution, lorsque la suite de tests est lancée (voir l'Annotation @group, le Lanceur de tests en mode ligne de commande et la documentation du Fichier de configuration XML dans le manuel PHPUnit pour les détails complémentaires).

Pour ajouter un test (ou une classe) à un groupe, utiliser l'annotation  dans la partie docblock qui précède le code. Par exemple :

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


 * API - Tests that exercise the MediaWiki API.
 * Broken - Place les tests en échec dans le groupe 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.


 * 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 - N'est pas utilisé actuellement par aucun test. Les tests de ce groupe ne seront pas exécutés (conformément à ce qui est configuré dans ).

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


 * Levée de fonds
 * Engagement du contributeur
 * Internationalisation
 * etc.

Pour tester simplement un groupe particulier, utiliser le drapeau  à partir de la ligne de commande.

php phpunit.php --group Search

ou si vous passez par le Makefile en core/tests/phpunit :

make FLAGS="--group Search" target

où la cible peut être : phpunit, safe, etc.

Couverture de test
La Documentation PHPUnit possède un chapître à propos de la couverture de test. Un rapport de couverture pour le noyau MediaWiki est généré deux fois par jour. Comme l'option forceCoversAnnotation doit être activée, le test doit être balisé avec des annotations @covers pour identifier les parties de code à tester (à la différence du code exécuté simplement et dont les résultats ne sont jamais testés avec des assertions),

Notez que  demande à avoir des noms de classes qui soient complètement qualifiés  (à la différence des annotations  telles que  ).

Classe
Il est possible d'étendre l'une des classes de test MediaWiki. The following are some common MediaWiki test classes to extend. Les puces de niveau inférieur étendent leurs parents.


 * - classe de test de PHPUnit
 * - For unit tests of true functions that don't have any dependencies. These are customarily put in their own subfolder called
 * - Assists with testing classes that access global variables, methods, services, or a storage backend. Empêche d'envoyer les courriels acuels. Quelques fois dans un sous-répertoire appelé . Can safely test the SQL database if you add   to your tests.
 * - Does some language setup such as  and   and does
 * - Has some extra methods such as,  ,  , etc.

Les bases de données
Si vous testez du code qui dépend de la base de données, vous devez mettre votre cas de test dans le groupe Database (voir ci-dessus). Cela indique à MediaWikiTestCase d'établir une connection à la base de données  que vous utiliserez dans. Normalement, cela utilise une base de données temporaire et distincte, avec des données limitées préremplies par, comprenant un utilisateur 'UTSysop' et un titre 'UTPage'. (La base de données temporaire est créée avec  et préfixée avec  ). Un cas de test peut ajouter des données supplémentaires à la base de données en réécrasant  (qui par défaut ne fait rien).

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

Les tests qui ne se trouvent pas dans le groupe Database sont encore exécutés avec une base de données clonée et temporaire (même s'ils ignorent et à la place utilisent par exemple  directment); néanmoins cette base n'est configurée qu'une seule fois pour toute la séquence de test et n'est pas réinitialisée entre les tests. Les tests doivent éviter de s'appuyer sur cette fonctionnalité de sécurité autant que possible.



Scripts de maintenance
Les cas de test pour les doivent hériter de, pour gérer les différents canaux de sortie utilisés par les scripts de maintenance.

La méthode du cas de test de base va instancier pour vous, votre objet   si vous indiquez la classe à construire en fournissant le  obligatoire dans votre sous-classe :

Dans le cas improbable où vous voudriez faire quelque chose de spécial pour instancier la classe à tester, vous pouvez réécraser la méthode, mais cela n'est heureusement pas nécessaire.

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 :