Les meilleures pratiques de PHPUnit pour organiser les tests

Question

Je vais actuellement repartir de zéro avec les tests phpunit pour un projet. Je me suis donc penché sur certains projets (comme Zend) pour voir comment ils font les choses et comment ils organisent leurs tests.

La plupart des choses sont assez claires, la seule chose qui me pose problème est l'organisation des suites de tests. Zend a un AllTests.php à partir duquel les autres suites de test sont chargées.
Il est difficile de regarder la classe qu'il utilise. PHPUnit_Framework_TestSuite pour créer un objet suite et y ajouter les autres suites, mais si je regarde dans la documentation de PHPUnit pour organiser les tests dans les versions de PHPUnit postérieures à 3.4, il n'y a qu'une description pour XML ou FileHierarchy. Celle utilisant les classes pour organiser les tests a été supprimée.
Je n'ai rien trouvé qui indique que cette méthode est dépréciée et des projets comme Zend l'utilisent toujours.

Mais si elle est dépréciée, comment pourrais-je organiser les tests dans la même structure avec la configuration xml ? Exécuter tous les tests n'est pas un problème, mais comment organiser les tests (dans le xml) si je ne veux exécuter que quelques tests. Peut-être en créant plusieurs xml où je ne spécifie que quelques tests/suites de tests à exécuter ?

Ainsi, si je veux tester uniquement le module 1 et le module 2 de l'application, dois-je avoir un xml supplémentaire pour chacun d'entre eux et définir des suites de tests uniquement pour ces modules (classes utilisées par le module). Et aussi un qui définit une suite de test pour tous les tests ?

Ou serait-il préférable d'utiliser le @group annotation sur les tests spécifiques pour les marquer comme étant pour le module1 ou le module2 ?

Merci d'avance de m'indiquer les meilleures pratiques.

Answer 1

Je commencerai par établir un lien avec le manuel, puis j'aborderai ce que j'ai vu et entendu sur le terrain.

Organisation des suites de tests phpunit

Module / Test de l'organisation des dossiers dans le système de fichiers

L'approche que je recommande est de combiner le système de fichiers avec une configuration xml.

tests/
 \ unit/
 | - module1
 | - module2
 - integration/
 - functional/

avec un phpunit.xml avec un simple :

<testsuites>
  <testsuite name="My whole project">
    <directory>tests</directory>
  </testsuite>
</testsuites>

vous pouvez diviser les testuites si vous le souhaitez mais c'est un choix de projet à projet.

Running phpunit exécutera ensuite TOUS les tests et l'exécution phpunit tests/unit/module1 exécutera tous les tests du module1.

Organisation du dossier "unité

L'approche la plus courante ici est de refléter votre source/ dans la structure des répertoires de votre tests/unit/ structure du dossier.

Vous avez une TestClass par ProductionClass de toute façon, donc c'est une bonne approche dans mon livre.

Dans l'organisation des fichiers

• Une classe par dossier.

Cela ne fonctionnera pas de toute façon si vous avez plus d'une classe de test dans un fichier, alors évitez ce piège.

• Ne pas avoir d'espace de nom de test

Cela rend juste l'écriture du test plus verbeuse car vous avez besoin d'une déclaration d'utilisation supplémentaire. Je dirais que la classe de test devrait être dans le même espace de noms que la classe de production mais ce n'est pas quelque chose que PHPUnit vous oblige à faire. J'ai juste trouvé que c'était plus facile et sans inconvénient.

Exécution de quelques tests seulement

Par exemple phpunit --filter Factory exécute tous les FactoryTests pendant que phpunit tests/unit/logger/ exécute tout ce qui concerne la journalisation.

Vous pouvez utiliser @group pour des numéros de numéros, des histoires ou autres, mais pour les "modules", j'utiliserais la disposition en dossiers.

Fichiers xml multiples

Il peut être utile de créer plusieurs fichiers xml si vous souhaitez en avoir :

• un sans couverture de code
• un seul pour les tests unitaires (mais pas pour les tests fonctionnels ou d'intégration ou les tests de longue durée)
• autres cas courants de "filtres
• PHPBB3, par exemple, le fait pour their phpunit.xmls

Couverture de code pour vos tests

Comme il est lié au démarrage d'un nouveau projet avec des tests :

• Ma suggestion est d'utiliser @covers tags comme décrit dans mon blog (Seulement pour les tests unitaires, toujours couvrir toutes les fonctions non publiques, toujours utiliser les balises de couverture.
• Ne générez pas de couverture pour vos tests d'intégration. Cela vous donne un faux sentiment de sécurité.
• Utilisez toujours la liste blanche pour inclure tout votre code de production afin que les chiffres ne vous mentent pas !

Autochargement et amorçage de vos tests

Vous n'avez pas besoin d'une sorte de chargement automatique pour vos tests. PHPUnit s'en chargera.

Utilisez le <phpunit bootstrap="file"> pour spécifier votre test bootstrap. tests/bootstrap.php est un bon endroit pour le mettre. Vous pouvez y configurer l'autoloader de vos applications et ainsi de suite (ou appeler vos applications "bootstrap").

Résumé

• Utilisez la configuration xml pour à peu près tout
• Séparation des tests unitaires et d'intégration
• Les dossiers de vos tests unitaires doivent refléter la structure des dossiers de vos applications.
• Pour n'exécuter que des tests spécifiques, utilisez phpunit --filter ou phpunit tests/unit/module1
• Utilisez le strict dès le départ et ne jamais l'éteindre.

Exemples de projets à examiner

• Projet d'exemple "Compte bancaire" de Sebastian Bergmanns
• phpBB3 Malgré cela, ils doivent se battre avec leur héritage ;)
• Symfony2
• Doctrine2