# Introduction au test logiciel/Tests unitaires/PHPUnit

* Introduction
* Tests unitaires
** JUnit
** PHPUnit
** SimpleTest
** Behat
* Doublures de test
* Tests et conception
* Qualité des tests
* Intégration dans le processus de développement
* Problématiques de tests
* Tests d'intrusion
* Conclusion
PHPUnit est utilisé dans un certain nombre de frameworks connus pour réaliser des tests unitaires. Sa documentation en anglais est disponible au format PDF.

## Installation
### Via wget

Une fois le .phar téléchargé depuis le site officiel, le copier dans le dossier où il sera toujours exécuté. Exemple :

#### Windows

* Ajouter à la variable d'environnement PATH, le dossier où se trouve le fichier (ex : ;C:\bin).
* Créer un fichier exécutable à côté (ex : C:\bin\phpunit.cmd) contenant le code : @php "%~dp0phpunit.phar" %*.
Par ailleurs, le code source de cet exécutable est sur GitHub.

### Test

Test de l'installation :

## Utilisation

Il faut indiquer au programme les dossiers contenant des tests dans le fichier phpunit.xml.dist. Exemple sur Symfony :
Si on a plusieurs dossiers à exclure, mieux vaut sélectionner plutôt ceux à traiter :
Ensuite, pour tester tous les fichiers du dossier /test et ignorer ceux de /src, il suffit de lancer :
Pour exclure un seul fichier ou une seule méthode des tests, lui mettre $this->markTestIncomplete('This test has to be fixed.');

### Options

Ce .xml donne des options par défaut qui peuvent être modifiées dans les commandes. Par exemple stopOnFailure="true" dans la balise <phpunit> peut être par défaut, et phpunit --stop-on-failure seulement pour ce lancement.

#### Choisir les tests à lancer

Si les tests sont longs et qu'on ne travaille que sur un seul fichier, une seule classe ou une seule méthode, on peut demander à ne tester qu'elle en précisant son nom (ce qui évite d'afficher des dumps que l'on ne souhaite pas voir lors des autres tests) :
Si une méthode dépend d'une autre, on ne n'appeler que ces deux-là (peu importe l'ordre) :

#### Détails de chaque test

Pour afficher les noms des tests et le temps qu'ils prennent, utiliser : --testdox

#### Rapports

Outre les résultats des tests, on peut avoir besoin de mesurer et suivre leur complétude, via le taux de couverture de code. PhpUnit permet d'afficher ce taux en installant Xdebug et en activant son option xdebug.mode = coverage.
Le calcul du taux de couverture peut ensuite être obtenu avec :
Certains fichiers ne peuvent en aucun cas être testés, et doivent donc être exclus du calcul du taux de couverture dans phpunit.xml.dist. Par exemple pour les migrations et fixtures :

##### Dans un fichier

Le résultat des tests peut être sauvegardé dans un fichier de rapport XML avec l'option --log-junit phpunit.logfile.xml.
L'ajout de l'option --coverage-html reports/ générera un rapport du taux de couverture des tests en HTML (mais d'autres formats sont disponibles tels que l'XML ou le PHP), dans le dossier "reports" (créé automatiquement).
Exemple récupérable par l'outil d'analyse de code SonarQube :

## Écriture des tests

La classe de test PHPUnit propose des dizaines d'assertions différentes.

### $this->fail

PhpUnit distingue pour chaque test, les erreurs (ex : division par zéro) des échecs (assertion fausse). Dans le cas où on on souhaiterait transformer les erreurs en échecs, on peut utiliser $this->fail :

### MockObject

Les mocks sont des objets PhpUnit qui permettent de simuler des résultats de classes existantes.

#### willReturn

Par exemple, pour simuler le résultat de deux classes imbriquées (en appelant la méthode d'une méthode), on leur crée une méthode de test chacune :
Pour qu'une méthode de mock réalise un "set" quand elle est appelée, il ne faut pas le faire directement dans le willReturn, auquel cas il s'effectue lors de sa définition, mais dans un callback. Ex :

#### willReturnArgument

Renvoie l'argument dont le numéro est en paramètre.

#### willThrowException

Pour qu'un mock simule une erreur. Ex :

#### expects

Dans l'exemple précédent, expects est un espion qui compte le nombre de passage dans la méthode, et le test échoue si ce résultat n'est pas 1. Ses valeurs possibles sont :
* $this->never : 0.
* $this->once : 1.
* $this->exactly(x) : x.
* $this->any.
De plus, on trouve $this->at pour définir un comportement dépendant du passage.

#### onConsecutiveCalls

Si la valeur retournée par le mock doit changer à chaque appel, il faut remplacer willReturn par onConsecutiveCalls.
Exemple :

#### with

Cette méthode permet de définir les paramètres avec lesquels doit être lancé une méthode mock. Ex :

#### disableOriginalConstructor

Cette méthode s'emploie quand il est inutile de passer par le constructeur du mock.

#### expectException

S'utilise quand le test unitaire doit provoquer une exception dans le code testé (ex : s'il contient un throw).
Si au contraire on veut vérifier que le code testé ne renvoie pas d'exception, on peut le lancer suivi d'une incrémentation des assertions :

## Attributs

PHPUnit depuis sa version 10 offre plusieurs attributs pour influencer les tests. Exemples :
* #[DataProvider] : indique un tableau d'entrées et de sorties attendues lors d'un test.
* #[Depends] : spécifie qu'une méthode récupère le résultat d'une autre (son return) dans ses arguments.

## Annotations

PHPUnit offre plusieurs annotations pour influencer les tests. Exemples :
* @covers : renseigne la méthode testée par une méthode de test afin de calculer le taux de couverture du programme par les tests.
* @uses : indique les classes instanciées par le test.
* @dataProvider : indique un tableau d'entrées et de sorties attendues lors d'un test.
* @depends : spécifie qu'une méthode récupère le résultat d'une autre (son return) dans ses arguments. Si elle appartient à un autre fichier, il faut renseigner son namespace : @depends App\Tests\FirstTest::testOne. Et comme PhpUnit exécute les tests dans l'ordre alphabétique des fichiers, il faut que le test se trouve après celui dont il dépend.

## JavaScript

En PHP, Selenium peut s'interfacer avec PHPUnit pour tester du JavaScript.
Avec Symfony, il existe aussi Panther.

## Symfony

Pour récupérer une variable d'environnement ou un service dans un test unitaire Symfony, il faut passer par setUpBeforeClass pour booter le kernel du framework :
Seuls les services publics seront accessibles. Mais il est possible de créer des alias publics des services accessibles uniquement en environnement de test grâce au fichier de config services_test.yaml.
Test fonctionnel :

## Références

* ↑ https://phpunit.de/manual/current/en/phpunit-book.pdf
* ↑ https://phpunit.de/
* ↑ https://github.com/sebastianbergmann/phpunit
* ↑ https://symfony.com/doc/current/testing.html
* ↑ https://phpunit.de/manual/current/en/test-doubles.html
* ↑ https://docs.phpunit.de/en/10.5/writing-tests-for-phpunit.html#data-providers
* ↑ https://phpunit.readthedocs.io/fr/latest/annotations.html
* ↑ https://blog.martinhujer.cz/how-to-use-data-providers-in-phpunit/
* ↑ Chaine complète de test avec Selenium IDE, Selenium RC et PHPUnit
* ↑ https://github.com/symfony/panther