RAPPEL:

1. PHPUnit doit avoir été installé de façon autonome.

   Attention, nous sommes contre l'installation de PHPUnit via Composer dans le projet lui-même.
   Un PHPUnit globalement disponible et avec très peu de maitenance vaut mieux que de versions
   multiples installées, prêtant à confusion et consommant de l'espace disque, de l'espace Git
   (le cas échéant) et de l'espace d'hébergement ; sans compter la confusion des jeunes développeurs.
   
2. Le fichier \application\third_party\CIUnit\bootstrap_phpunit.php doit avoir été activé 
   pour que PHPUnit marche avec notre framework.
   
   Si PHPUnit a été installé sous forme de fichier unique .phar, alors la ligne chargeant PHPUnit/Autoload.php 
   doit être désactivée car elle n'est plus applicable.
   
3. Le fichier \tests\phpunit.xml doit avoir été activé pour que PHPUnit trouve sa configuration.

4. Ce document décrit le lancement des tests ; pour des indications sur la façon de les coder, 
   notamment en lien avec les jeux de données (fixtures), voir le read-me dans le répertoire fixtures/,
   et le cas échéant les fihiers exemples dans les sous-répertoires.

HOW-TOs:

$ php generate_populated_fixtures.php fixtures -f <table>

    Pas encore PHPUnit, mais si on désire générer un jeu de données pour <table>
    à partir des données qui y existent (dans la base _test, pas la base _dev). 
    Attention, le fichier généré s'appellera fixtures/<table>_fixt.yml et *écrasera* 
    sans avertissement un fichier de même nom. Il est donc préférable de renommer 
    tout de suite le fichier .yml ainsi généré.

$ phpunit

    Pour lancer tous les tests sans distinction dans le répertoire et ses sous-répertoires.
    
    La succès est indiqué par la présence de points "." uniquement.
    Les assertions non vérifiées (logique applicative) sont signalés par des "F" parmi les points.
    Les erreurs (bugs PHP) sont signalés par des "E" parmi les points.
    Les tests non exécutés (suspendus explicitement) sont signalés par des "S" parmi les points.
    
$ phpunit models\ClientsTest.php

    Exécuter un jeu de tests particulier nommé ClientsTest.php situé dans le dossier models.
    
$ phpunit --filter testSomeTest models\ClientsTest.php

    Pour n'executer qu'un test (méthode) parmi le jeu de tests (fichier).

$ phpunit --group auth

    Pour n'executer que les tests (méthode) marqués avec "@group auth".
    C'est chaque méthode qui est à marquer une à une.
    Une méthode peut être marquée avec plusieurs @group (une ligne à la fois)
    
$ phpunit --exclude-group auth-and-auth,library,importations

    Pour tout tester sauf les tests (méthodes) marqués avec les annotations
    "@group auth-and-auth", "@group library" et "@group importations"

$ phpunit --testdox ...

    Exécuter les tests en les listant leurs noms ligne par ligne et au fur et à mesure.
    Les tests OK sont marqués par un "[X]" et les tests en échec sont marqués par un "[ ]".
    Les noms des méthodes de test sont utilisés pour tenter de former des phrases lisibles.
    Utile pour documenter périodiquement l'ensemble des tests et aider à leur organisation.

$ phpunit -d max_execution_time=0

    Expérimental pour nous. Pas encore prouvé. Nous avons recontré des cas où explicitement
    il est d'un qu'un max execution time a été dépassé. Pourtant, il y avait beaucoup de 
    données contradictoires: 1) d'une part on dit que la limite de temps dans le PHP.INI 
    n'est pas respecté par le CLI et qu'il n'y a pas de limite dans ce mode quelle que soit
    la valeur inscrite. 2) d'autre part la valeur qui y était inscrite était de 120 secondes
    pour PHP 5.6 alors actif en CLI, alors que nous avions un message d'erreur pour un dépassement 
    de 300 secondes. 3) enfin, c'était la première fois qu'un test affichait une telle erreur 
    explicitement et nous avons supposé que cela vient peut-être du phpunit.phar ; d'où cette
    syntaxe que nous validerions ou rejeterions au fil du temps.

$ phpunit --configuration phpunit_9.5.0.xml

    Permet de changer de fichier de configuration.
    Utile lors du portage de codes de test d'une version de PHPUnit à une autre:
    La 9.5 déclare ne plus supporter le format d'avant et proposait une migration automatique
    en lançant la commande $ phpunit --migrate-configuration; nous avons alors renommé la nlle
    config nénérée pour l'utiliser lorsque c'est la 9.5 qui est utilisée.
    
    
    
Signification des outputs (2021-01-05)

    .   Printed when the test succeeds.
    F   Printed when an assertion fails while running the test method.
    E   Printed when an error occurs while running the test method.
    R   Printed when the test has been marked as Risky (see Chapter 6).
    S   Printed when the test has been Skipped (see Chapter 7).
    I   Printed when the test is marked as being incomplete or not yet implemented (see Chapter 7).
    W   is for Warning (not in documentation, seen in source code /5.7/src/TextUI/ResultPrinter.php#L454)