Jérôme Cutrona

Version statique de l'intranet de Jérôme Cutrona - Rejoindre la version dynamique 🔒

Les exemples et corrections sont potentiellement non fonctionnels.

B.U.T. Informatique - IUT de Reims - Université de Reims

Tests avec PHPUnit

Navigation
  1. Accueil
  2. Programmation Web S4
  3. Objectifs de la séance
  4. Quelques considérations liées à la configuration système de l'IUT
    1. En fin de séance
    2. En début de séance
  5. Versionnage du projet
    1. Initialisation du dépôt
    2. Consignes
  6. Installer et configurer Composer
  7. Initialiser le projet Composer
  8. Création du projet dans PhpStorm
  9. Installation des outils de qualité de code
    1. PHPUnit
    2. PHP CS Fixer
    3. PHP Mess Detector
    4. GrumPHP
    5. Scripts Composer
  10. Configuration du projet
  11. Développement guidé par les tests, un exemple
  12. Premiers tests et (re)découverte de PhpStorm
    1. Définition d'une classe « FloatCalculator »
    2. Définition de la classe de test
    3. Mise en place d'une « fixture » et suite des tests
    4. Prise en compte de la précision de la représentation des nombres en virgule flottante
  13. Doublures de test
    1. « Mock objects »
    2. Modification de la conception pour rendre le système plus testable
    3. Fiabilisation par l'introduction de constantes
    4. « Stubs »
  14. Couverture de code

Objectifs de la séance

  • Créer un nouveau projet avec Composer
  • Installer PHPUnit
  • Installer des outils de tests statiques dans PhpStorm
  • Installer et configurer PHP Coding Standards Fixer (a.k.a. PHP CS Fixer)
  • Installer et configurer PHP Mess Detector
  • Prendre en main PHPUnit
  • Écrire des tests unitaires
  • Écrire des tests d'intégration
  • Utiliser des « stubs »
  • Utiliser des « mock objects »
  • Découvrir l'analyse de couverture de code

Quelques considérations liées à la configuration système de l'IUT

Remarque importante

Si vous travaillez sur votre ordinateur personnel, sur Linux ou sur Windows, vous pouvez placer le répertoire tests-phpunit du projet où bon vous semble. La partie qui suit concerne uniquement le travail sur les ordinateurs de l'IUT. Cele ne vous empêche pas d'en prendre connaissance.

Votre répertoire d'accueil $HOME se trouve sur un emplacement réseau NFS, ce qui vous permet de retrouver vos fichiers quel que soit le PC du département sur lequel vous vous connectez. PHPUnit, installé par Composer, utilise le sous-répertoire vendor qui contient les sources de PHPUnit et de toutes les bibliothèques qu'il utilise, ainsi que les outils PHP Coding Standards Fixer et PHP Mess Detector. L'accès à ces nombreux fichiers (plus de 4000 fichiers et presque 900 répertoires) produit de nombreuses entrées-sorties sur le système de fichiers, particulièrement inadaptées aux systèmes de fichiers en réseau. Il en va de même pour PhpStorm qui surveille les modifications de tous les fichiers de votre projet et ne peut pas fonctionner normalement lorsque ces fichiers sont sur un partage NFS. Afin d'améliorer la réactivité du système pendant vos TP et d'éviter de saturer le serveur de fichiers du département informatique, vous allez travailler dans le répertoire « /working/votre_login » de la machine sur laquelle vous êtes connecté.

En fin de séance

En fin de séance, vous devez impérativement synchroniser votre dépôt distant (en ligne de commande ou avec PhpStorm) 

git commit
puis 
git push
faute de quoi vous perdrez votre travail entre chaque séance !

Pensez également à supprimer votre répertoire de travail /working/votre_login/tests-phpunit pour éviter la saturation du disque local : 

rm -Rf /working/votre_login/tests-phpunit

En début de séance

Lorsque vous reprenez le travail la séance suivante, vous avez trois choix possibles, qui dépendent de la façon dont vous avez travaillé :

  • Mettre à jour votre dépôt local 
    cd /working/votre_login/tests-phpunit
    git pull
  • Effacer votre dépôt local et repartir de zéro 
    cd /working/votre_login
    rm -Rf /working/votre_login/tests-phpunit
    git clone https://iut-info.univ-reims.fr/gitlab/votre_login/tests-phpunit.git
    cd /working/votre_login/tests-phpunit
  • Réinitialiser votre dépôt local selon le dépôt distant 
    cd /working/votre_login/tests-phpunit
    git fetch
    git reset --hard origin/main

Ensuite, dans le répertoire de votre projet, vous devez et (ré)installer les composants nécessaires à son fonctionnement : 

composer install

Versionnage du projet

Pour ce sujet de TP, vous créerez un nouveau répertoire, vous initialiserez un dépôt Git dans ce répertoire et créerez un dépôt distant sur GitLab. Vous réaliserez une opération de validation avec git commit au moins une fois par question du sujet.

Initialisation du dépôt

  • Ouvrez un terminal puis utilisez la commande mkdir un_nom_de_répertoire pour créer un nouveau répertoire « tests-phpunit » dans « /working/votre_login » suivie de la commande cd un_chemin_relatif_ou_absolu pour vous placer dans le répertoire
  • Initialisez le dépôt Git du projet 
    git init
  • Effectuez une première validation 
    git commit --allow-empty -m "Initial commit"
  • Éditez le fichier « .gitignore » pour exclure les fichiers binaires inutiles à votre projet (fichiers pptx du cours, …), les fichiers qui contiennent des mots de passe ou, dans le cas des projets collaboratifs, les fichiers créés par votre éditeur de texte (répertoire « .idea » pour PhpStorm)
  • Éditez un fichier « README.md » dans lequel doivent figurer :
    • un titre de niveau 1 contenant le titre explicite du projet
    • un titre de niveau 2 « Auteur(s) » vous permettant de préciser votre nom et votre prénom (ainsi que ceux de votre binôme, le cas échéant)
    • un titre de niveau 2 « Installation / Configuration » précisant les points essentiels permettant d'installer, de configurer et de lancer le projet
  • Ajoutez les fichiers au dépôt 
    git add .
  • Effectuez une nouvelle validation 
    git commit -m "Repository setup"
  • Si nécessaire, renommez la branche principale en « main » (une branche vide ne peut pas être renommée, c'est pourquoi ceci est fait après le premier commit) 
    git branch -m main
    Notez que vous pouvez le faire de façon définitive avec la commande suivante, à condition d'utiliser git dans une version supérieure à 2.28 
    git config --global init.defaultbranch main
  • Connectez-vous à l'application GitLab et créez un dépôt portant le même nom que votre nouveau répertoire en pensant à décocher la case « Initialize repository with a README »
  • Accordez la permission « Reporter » à votre enseignant de TP/TD
  • Associez le dépôt local et le dépôt distant 
    git remote add origin https://iut-info.univ-reims.fr/gitlab/votre_login/tests-phpunit.git
  • Poussez le dépôt local vers le dépôt distant 
    git push -u origin main

Consignes

  • Vous effectuerez une validation après chaque question.
  • À la fin de chaque séance, vous effectuerez une validation. Si cette validation contient du code incomplet ou ne fonctionnant pas, mentionnez-le dans le message de validation. Vous pousserez ensuite votre travail vers le dépôt distant.
  • Ce dépôt sera utilisé par votre enseignant(e) de TP pour évaluer votre travail, que cela conduise à un note ou pas. Assurez-vous donc régulièrement que tous les fichiers que vous souhaitez lui rendre sont bien présents dans le dépôt. Respectez les noms des fichiers qui vous sont demandés si des consignes particulières vous sont données.
  • Le dépôt lui-même sera évalué, soignez l'écriture de vos messages : clarté, pertinence, orthographe.

L'aide-mémoire Git et l'aide-mémoire GitLab de Monsieur Nourrit pourront vous être utiles.

Installer et configurer Composer

Composer simplifie grandement la gestion de projets PHP. Afin d'accélérer les installations futures et de limiter l'impact sur votre quota d'espace disque, nous allons déporter le cache de Composer dans le répertoire temporaire.

Travail à réaliser

Initialiser le projet Composer

Vous allez initialiser un projet Composer pour installer des paquets et profiter de l'auto-chargement.

Attention commit = danger !

Dans cette partie, ne faites PAS de commit tant que cela ne vous est pas demandé. Vous devrez dans un premier temps vérifier ou compléter votre fichier .gitignore pour ne pas intégrer inutilement des centaines de fichiers et de répertoires à votre dépôt.

Travail à réaliser
  1. Dans le répertoire de votre projet, initialisez interactivement un nouveau projet Composer : 
    composer init

                                            
  Welcome to the Composer config generator  
                                            


This command will guide you through creating your composer.json config.

Package name (<vendor>/<name>) [cutron01/tests-phpunit]: 
Description []: Découverte des tests unitaires avec PHPUnit
Author [Jérôme Cutrona <jerome.cutrona@univ-reims.fr>, n to skip]: 
Minimum Stability []: 
Package Type (e.g. library, project, metapackage, composer-plugin) []: project
License []: Copyleft

Define your dependencies.

Would you like to define your dependencies (require) interactively [yes]? no
Would you like to define your dev dependencies (require-dev) interactively [yes]? no
Add PSR-4 autoload mapping? Maps namespace "Cutron01\TestsPhpunit" to the entered relative path. [src/, n to skip]: 

{
    "name": "cutron01/tests-phpunit",
    "description": "Découverte des tests unitaires avec PHPUnit",
    "type": "project",
    "license": "Copyleft",
    "autoload": {
        "psr-4": {
            "Cutron01\\TestsPhpunit\\": "src/"
        }
    },
    "authors": [
        {
            "name": "Jérôme Cutrona",
            "email": "jerome.cutrona@univ-reims.fr"
        }
    ],
    "require": {}
}

Do you confirm generation [yes]? 
Generating autoload files
Generated autoload files
Would you like the vendor directory added to your .gitignore [yes]? 
PSR-4 autoloading configured. Use "namespace Cutron01\TestsPhpunit;" in src/
Include the Composer autoloader with: require 'vendor/autoload.php';
  2. Constatez l'apparition du répertoire vendor
  3. Vérifiez le contenu du fichier .gitignore afin de vous assurer que le répertoire vendor est bien exclu
  4. Vérifiez le contenu de l'index avec la commande : 
    git status
    dont le résultat doit être : 
    Sur la branche main
Votre branche est à jour avec 'origin/main'.

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
	modifié :         .gitignore

Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)
	composer.json

aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)
    Remarque importante

    le répertoire vendor ne doit PAS être présent dans la précédente liste de fichiers non suivis. Si tel est le cas, votre fichier .gitignore est incorrect ou mal nommé.

  5. Ajoutez les fichiers à l'index Git 
    git add .
  6. Enregistrez les modifications dans le dépôt : 
    git commit
  7. Poussez les modifications sur le dépôt distant : 
    git push
  8. Vérifiez le contenu du dépôt distant sur https://iut-info.univ-reims.fr/gitlab/

Création du projet dans PhpStorm

La gestion de nombreux fichiers dans une arborescence complexe demande un IDE adéquat. Vous utiliserez PhpStorm pour l'édition de code et la gestion globale du projet. Des greffons apportent le support de Symfony, Composer, PHPUnit, des fichiers YAML, Twig, … Certains sont préinstallés dans la configuration générale.

Vous allez créer un nouveau projet PhpStorm pour gérer vos sources et vos suites de tests.

Référez-vous au sujet Installation et configuration de PhpStorm.

Travail à réaliser
  1. Dans votre terminal et dans le répertoire du projet, lancez la commande 
    phpstorm . &
    Information

    Cette commande est la façon la plus simple et la plus rapide de créer un nouveau projet PhpStorm dans un répertoire. Il n'est pas utile de la lancer une fois le projet créé puisque vos anciens projets sont proposés à l'ouverture de PhpStorm ou dans son menu « File » puis « Recent Projects ».

  2. Patientez pendant l'indexation des fichiers du projet visible dans la partie droite de la barre d'état Indexation du projet
    Information

    Il est légitime d'inclure à votre index Git le répertoire « .idea » de configuration de PhpStorm afin que vous n'ayez pas à reconfigurer votre environnement lorsque vous clonerez votre dépôt en début de séance lors d'un changement de salle. Veillez néanmoins à effectuer des commits distincts pour les modifications de ce répertoire.

Installation des outils de qualité de code

La qualité de votre code, par son style cohérent ou l'absence de problèmes potentiels, est un atout majeur pour la maintenance et la fiabilisation de vos applications. Vous avez jusqu'à présent utilisé PHP CS Fixer pour standardiser votre style de codage. Vous allez à présent découvrir PHP Mess Detector, un autre outil d'analyse statique de code, dont l'objectif est de mettre en évidence des problèmes potentiels de nommage, de conception, de taille de code ou encore de code inutile.

La qualité du code passe également par des tests unitaires, fonctionnels ou d'intégration pour analyser dynamiquement le comportement du code testé. Aussi, vous utiliserez PHPUnit et écrirez vos premiers tests unitaires pour valider le fonctionnement de votre code.

Ces trois outils, aussi puissants soient-ils, ne servent à rien si vous ne prenez pas la peine de les exécuter, de lire leurs alertes ou de suivre leurs suggestions. C'est pourquoi vous allez utiliser GrumPHP ! Cet outil de qualité de code s'appuie sur les « hooks » de Git pour se déclencher avant chaque commit et appliquer certaines tâches de contrôle. Il peut alors interrompre le commit si les tâches échouent. Il devient donc impossible d'ajouter du code de mauvaise qualité (au sens des tests mis en place) au dépôt Git local, et au dépôt distant par voie de conséquence.

PHPUnit

PHPUnit exécute les codes à travers les tests qui décrivent son comportement attendu. C'est un outil puissant et reconnu sur lequel s'appuient la plupart des outils de test dynamique de code PHP.

Travail à réaliser
  1. Recherchez le paquet de PHPUnit à l'aide de Composer : 
    composer search phpunit
  2. Installez PHPUnit à l'aide de Composer
    Remarque importante

    La version 10 de PHPUnit vient juste de sortir. Afin d'éviter tout problème, vous installerez la version 9 sur laquelle ce TP a été conçu. N'oubliez pas de forcer la version à l'installation ! 

    composer require --dev phpunit/phpunit:^9
  3. Constatez l'apparition du répertoire « vendor/bin »
  4. Observez le contenu du répertoire « vendor/bin »
  5. Vérifiez que PHPUnit fonctionne : 
    vendor/bin/phpunit --version
PHPUnit 9.6.3 by Sebastian Bergmann and contributors.
  6. Générez un fichier de configuration avec la commande : 
    vendor/bin/phpunit --generate-configuration
PHPUnit 9.6.3 by Sebastian Bergmann and contributors.

Generating phpunit.xml in /working/votre_login/tests-phpunit

Bootstrap script (relative to path shown above; default: vendor/autoload.php): 
Tests directory (relative to path shown above; default: tests): 
Source directory (relative to path shown above; default: src): 
Cache directory (relative to path shown above; default: .phpunit.cache): 

Generated phpunit.xml in /working/votre_login/tests-phpunit.
Make sure to exclude the .phpunit.cache directory from version control.
  7. Passez l'option « forceCoversAnnotation » à « false »
  8. Excluez le répertoire « .phpunit.cache » des fichiers suivis du dépôt

PHP CS Fixer

PHP CS Fixer, outil d'analyse statique de code développé par Fabien Potencier, créateur de Symfony, détecte ou corrige les défauts de style de codage de vos sources.

Travail à réaliser
  1. Placez le fichier de configuration de PHP CS Fixer (télécharger) à la racine de votre projet (le style de codage défini est ici Symfony)
    Remarque importante

    Votre navigateur risque de renommer en php-cs-fixer.dist.php, supprimant ansi le . initial. Veillez à ce que le nom du fichier soit bien .php-cs-fixer.dist.php.

  2. Référez-vous au sujet Installation et configuration de PhpStorm pour installer et configurer PHP CS Fixer
  3. Exluez le fichier .php-cs-fixer.cache du dépôt Git

PHP Mess Detector

PHP Mess Detector est un analyseur statique de code basé sur PHP Depend qui mettra en évidence des bugs, du code sous-optimal, une complexité trop élevée ou des éléments inutilisés.

Travail à réaliser
  1. Référez-vous au sujet Installation et configuration de PhpStorm pour installer et configurer PHP Mess Detector
  2. Placez le fichier de configuration de PHP Mess Detector (télécharger) à la racine de votre projet (la détection porte sur toutes les règles possibles)
    Information

    Si vous avez correctement suivi le guide d'installation de PHP Mess Detector, vous devez avoir une configuration de PHP Depend. Elle est indispensable sur les PC de l'IUT. En effet, PHP Depend génère des fichiers et répertoire de cache dans « $HOME/.pdepend », donc dans le système de fichier partagé en NFS, ce qui ralentit considérablement le temps d'analyse des fichiers du projet.

GrumPHP

GrumPHP vient parfaire votre contrôle de code en le validant avant chaque commit. Dans un cadre d'un développement logiciel avec intégration continue, il doit être impossible d'introduire du code non valide dans le dépôt central et GrumPHP permet de s'en assurer.

Remarque importante

Dans le cadre des TP, il n'est pas possible de vous interdire de soumettre du code invalide, tout particulièrement lors du « commit de fin de séance ». Il vous sera donc possible, uniquement à cette occasion, de soumettre du code non validé. Pour cela, vous utiliserez l'option « --no-verify » de git en ligne de commande qui permet de sauter les « hooks » et donc l'exécution de GrumPHP. Vous ferez alors mention de l'état invalide du code dans le message de commit.

Travail à réaliser
  1. Installez GrumPHP à l'aide de Composer 
    composer require --dev phpro/grumphp
    Remarque importante

    Deux questions vous sont posées pendant l'installation.

    Répondez « y » à la question suivante : 

    phpro/grumphp contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "phpro/grumphp" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?]

    Répondez « n » à la question suivante : 

    Run composer recipes at any time to see the status of your Symfony recipes.
Do you want to create a grumphp.yml file? [Yes]:
  2. Placez le fichier de configuration de GrumPHP (télécharger) à la racine de votre projet
  3. Observez les tâches du fichier de configuration fourni et lisez la documentation associée à chacune d'entre elles
  4. Afin de vérifier le bon fonctionnement de GrumPHP :
    1. Supprimez la description de votre projet dans « composer.json »
    2. Ajoutez le fichier « composer.json » à l'index Git : 
      git add composer.json
    3. Tentez de valider votre modification : 
      git commit -m "test GrumPHP"
GrumPHP detected a pre-commit command.
GrumPHP is sniffing your code!

Running tasks with priority 0!
==============================

Running task 1/4: composer... ✘
Running task 2/4: phpcsfixer2... 
Running task 3/4: phpmd... 
Running task 4/4: phpunit... 

             ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
           ▄▄▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌
         ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▄
        ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌
       ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌
  ▄███▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌
 █▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌
 ▐█▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌
   ▀█▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌
     ▀▀▓▓▓▓▓▓▓▓▓▓▓▓█▀▀▀▀▀▀▀▀▀▀▀▀▀▀████████████▄
      ▄███████                       ██████████
     ███████▀  ▀▀▀▀▀▄      ▄▀▀▀▀▀     █████ ▀
      ▐████      ▐██        ▐██        ████▌
      ████▌                            ███
       ▌██▌           ▄▄ ▄▄           ▐███
        ███       ▄▄▄▄▄▄▄▄▄▄▄▄       ▐███
         ██▄ ▐███████████████████████████
        █▀███████████▀     ▀▀███████████
          ██████████▄███████▄███████████
         ▐█████████████████████████████
          █████████████████████████████
           ██ █████████████████████▐██▀
            ▀ ▐███████████████████▌ ▐▀
                ████▀████████▀▐███
                 ▀█▌  ▐█████  ██▌
                        ██▀   ▐▀

       ██████████████████████████████████
       █░░░░░░▀█▀░░░░░░▀█░░░░░░▀█▀░░░░░▀█
       █░░▐█▌░░█░░░██░░░█░░██░░░█░░░██░░█
       █░░▐█▌░░█░░░██░░░█░░██░░░█░░░██░░█
       █░░▐█▌░░█░░░██░░░█░░░░░░▄█░░▄▄▄▄▄█
       █░░▐█▌░░█░░░██░░░█░░░░████░░░░░░░█
       █░░░█░░░█▄░░░░░░▄█░░░░████▄░░░░░▄█
       ██████████████████████████████████


composer
========

./composer.json is valid for simple usage with Composer but has
strict errors that make it unable to be published as a package
See https://getcomposer.org/doc/04-schema.md for details on the schema
# Publish errors
- description : The property description is required
    4. Si le test de commit n'a pas déclenché GrumPHP, initialisez-le dans votre projet avec : 
      vendor/bin/grumphp git:init
    5. Si le test de commit n'avait pas déclenché GrumPHP et que vous souhaitez défaire votre dernier commit : 
      git reset --soft HEAD~1
    6. Annulez la suppression de la description de votre projet dans « composer.json » (« CTRL+Z » dans votre IDE)
Information

Si vous utilisez les fonctionnalités Git à travers PhpStorm sur Linux, vous rencontrerez certainement le message d'erreur suivant, rendant impossible la validation de la tâche « composer » : 

The executable for "composer" could not be found.

Ceci est lié à l'installation de Composer dans la sous-arborescence des fichiers de l'utilisateur ainsi qu'à la configuration de l'environnement du « shell » « bash » lié à ses divers fichiers d'initialisation.

La solution la plus appropriée est de déporter la configuration de la variable « PATH » dans le fichier « $HOME/.profile ». Vous devez donc transférer les lignes concernées du fichier « $HOME/.bashrc » vers « $HOME/.profile » (que vous devez créer s'il n'existe pas dans votre compte).

Scripts Composer

Pour faciliter l'invocation des divers outils de qualité de code, vous pouvez utiliser les scripts Composer. Pour gagner un peu de temps, nous vous proposons de copier les scripts fournis :

  • test:cs qui vérifie le style de codage avec PHP CS Fixer
  • fix:cs qui arrange le style de codage avec PHP CS Fixer
  • test:md qui vérifie le style de codage avec PHP Mess Detector
  • test:phpunit qui lance les tests définis avec PHPUnit
  • test qui lance tous les tests définis précédemment
  • grumphp:precommit qui lance les tâches définies avec GrumPHP sur les fichiers indexés dans Git (ne donc pas oublier les « git add » !
  • grumphp:run qui lance les tâches définies avec GrumPHP sur tous les fichiers
Travail à réaliser
  1. Ajoutez les scripts suivants au fichier composer.json :
    Information

    Il est possible d'invoquer un script Composer sans donner son nom complet, à condition que le nom tronqué conduise à un seul choix possible. À titre d'exemple, dans les scripts fournis, la commande 

    composer grumphp:precommit
    peut être abrégée en 
    composer grumphp:p

Configuration du projet

Avant de commencer à coder, quelques consignes seront à respecter pour s'approcher de la structure de fichiers habituelle des projets écrits en PHP et ainsi permettre bien valider votre code avec les tests :

  • Les sources se trouvent dans un répertoire src
  • Les tests se trouvent dans un répertoire tests
  • La classe L\Espace\De\Noms\MaClasse se trouve dans le fichier src/L/Espace/De/Noms/MaClasse.php
  • Les tests de la classe L\Espace\De\Noms\MaClasse se trouvent dans le fichier tests/L/Espace/De/Noms/MaClasseTest.php
  • Un fichier contenant une classe ne fait pas d'inclusions (require, …), ceci est à la charge de l'application
  • Un fichier contenant une classe de test ne fait pas d'inclusions (require, …), ceci est à la charge du framework de tests
  • Afin de détecter les problèmes liés au type des variables, il est demandé, dans chacune de vos classes et dans chacun de vos tests, de :
    • passer en typage strict
    • de définir les types des propriétés des instances
    • de définir les types de retour et de paramètres des méthodes

Ces consignes impliquent la création de répertoires ainsi que la configuration de l'auto-chargement par Composer.

Travail à réaliser
  1. Vérifiez que la version de PHP indiquée dans PhpStorm soit la bonne
  2. Vérifiez que les modèles de PhpStorm intègrent le typage strict
  3. Configurez les outils d'analyse statique / de tests statiques de code PHP
  4. Créez les répertoires src et tests : 
    mkdir src tests
  5. Lisez la documentation de Composer sur l'auto-chargement PSR-4
  6. Ouvrez le fichier composer.json
  7. Modifiez l'auto-chargement PSR-4 dans le fichier composer.json pour charger l'ensemble des espaces de noms depuis le répertoire src/ (ensemble des espaces de noms = pas de restriction)
  8. Ajoutez l'auto-chargement PSR-4 de développement dans le fichier composer.json pour charger l'espace de noms « Tests » depuis le répertoire tests/
  9. Mettez à jour l'auto-chargement de Composer à l'aide de l'option dump-autoload 
    composer dump-autoload
Generating autoload files
Generated autoload files
Information

L'auto-chargement PSR-4 ne nécessite PAS de refaire la commande composer dump-autoload lors de l'ajout de nouvelles classes dans le répertoire src. Cette commande est nécessaire uniquement en cas de modification de la configuration d'auto-chargement.

Développement guidé par les tests, un exemple

Vous n'avez pas encore écrit de tests pour PHPUnit mais vous pouvez tout de même commencer à vous approprier cet outil. Vous allez valider le bon fonctionnement de votre code avec des tests. À vous d'écrire le code qui permet de passer les tests fournis.

Vous travaillerez sur la génération de « slug » à partir des textes variés.

La classe développée sera la suivante : classe Slug\Slugger

Le diagramme précédent est celui de la classe « Slug\Slugger ».
Travail à réaliser
  1. Lancez la création d'une nouvelle classe dans le répertoire « src » avec PhpStorm : PhpStorm create class
  2. Nommez cette nouvelle classe Slugger dans le namespace Slug : PhpStorm create class details
  3. PhpStorm vous propose de suivre les modifications de ce nouveau fichier : PhpStorm create class git add
  4. Écrivez le squelette de la classe « Slug\Slugger » selon les spécifications fournies dans le diagramme de classe
  5. Placez le fichier de tests SluggerTest.php (télécharger) dans le répertoire tests/Slug
  6. Lancez les tests en utilisant la sortie au format « TestDox », ils sont suffisamment lisibles et parlants pour vous guider dans votre réalisation : 
    vendor/bin/phpunit --color --testdox tests/Slug/SluggerTest.php
PHPUnit 9.6.3 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.1.14
Configuration: /working/cutron01/dev/tests-phpunit/phpunit.xml

Slugger (Tests\Slug\Slugger)
 ✘ Slugify with identity  13 ms
   ┐
   ├ «abcdef»                                      
   ├ should be slugified to                          
   ├ «abcdef»                                      
   ├ Failed asserting that two strings are identical.
   ┊ ---·Expected
   ┊ +++·Actual
   ┊ @@ @@
   ┊ -'abcdef'
   ┊ +'aabcdef'
   │
   ╵ /working/cutron01/dev/tests-phpunit/tests/Slug/SluggerTest.php:18
   ┴
…
    Information

    À titre de comparaison, voici le résultat du test précédent avec le format de sortie par défaut, bien moins lisible : 

    vendor/bin/phpunit --color tests/Slug/SluggerTest.php
PHPUnit 9.6.3 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.1.14
Configuration: /working/cutron01/dev/tests-phpunit/phpunit.xml

FFFFFFFFFFFF                                                      12 / 12 (100%)

Time: 00:00.023, Memory: 6.00 MB

There were 12 failures:

1) Tests\Slug\SluggerTest::testSlugify with data set "more html tags stripping" ('<em>abc</em>de<a href="about:...e></a>', 'abcdef')
«<em>abc</em>de<a href="about:blank"><code>f</code></a>»
should be slugified to
«abcdef»
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'abcdef'
+'aabcdef'

/working/cutron01/dev/tests-phpunit/tests/Slug/SluggerTest.php:18

    Vous pouvez activer la sortie au format « TestDox » de plusieurs façons :

    • en utilisant l'option --testdox de PHPUnit
    • en modifiant le fichier de configuration « phpunit.xml » pour ajouter l'attribut « testdox="true" » à la balise XML « phpunit »

    La transformation du nom « camel case » de la méthode de test en une phrase compréhensible doit vous pousser à nommer correctement toutes vos méthodes de test.

  7. Réalisez la méthode slugify() qui transforme un texte, généralement HTML, en une étiquette répondant aux contraintes suivantes :

Premiers tests et (re)découverte de PhpStorm

Vous allez bientôt écrire vos premiers tests avec PHPUnit. Avant cela, vous devez disposer de code à tester et vous allez donc écrire une classe très simple, Calculator\FloatCalculator.

Définition d'une classe « FloatCalculator »

La classe se propose d'effectuer des calculs avec des nombres réels.

Les spécifications sont les suivantes : classe Calculator\FloatCalculator

Le diagramme précédent est celui de la classe Calculator\FloatCalculator.
Travail à réaliser
  1. Créez une nouvelle classe Calculator\FloatCalculator dans le répertoire src à l'aide de PhpStorm et ajoutez le fichier au dépôt Git
  2. Copiez la méthode add() de la classe FloatCalculator : 
        /**
     * Méthode d'addition de deux nombres flottants
     * @param float $a Premier opérande
     * @param float $b Second opérande
     * @return float Somme des deux opérandes
     */
    public function add(float $a, float $b): float {
        return $a+$b;
    }
  3. Observez les informations fournies par PHP CS Fixer et PHP Mess Detector qui provoquent le soulignement du code problématique : PhpStorm cs-fixer check code
  4. Laissez le curseur de la souris sur le premier texte surligné pour voir le problème mis en évidence par PHP CS Fixer et PHP Mess Detector : PhpStorm cs-fixer check code message
  5. Vous pouvez faire apparaître le bouton de suggestions ou utiliser le lien dans la fenêtre d'informations pour corriger l'ensemble du fichier avec PHP CS Fixer : PhpStorm cs-fixer fix code
  6. Constatez les modifications apportées à la mise en forme du code
  7. Une fois le fichier corrigé automatiquement par PHP CS Fixer, des erreurs mises en évidence par PHP Mess Detector subsistent : PhpStorm php-md check code
  8. Placez-vous sur la variable $a et appuyez sur SHIFT + F6 pour renommer la variable en $firstOperand : PhpStorm refactor variable
  9. Constatez que la variable a été renommée partout où elle est utilisée dans la méthode : dans les paramètres, dans la méthode et dans la documentation
  10. Renommez le paramètre $b de la même façon
  11. Écrivez l'ensemble des méthodes de la classe FloatCalculator
    Information

    La classe étant extrêmement simple, peu d'explications sont nécessaires. Pensez tout de même à lever des exceptions de type RuntimeException en cas de division par zéro. Nous parlons bien ici de la classe RuntimeException de PHP et qui se trouve donc dans l'espace de noms global.

    Consultez la documentation sur le nombre d'arguments variable afin de réaliser la méthode sum().

Définition de la classe de test

La classe étant à présent écrite, il convient de vérifier son comportement. Vous allez donc définir une classe de test et écrire un ou plusieurs tests par méthode afin de couvrir l'ensemble du code que vous avez produit.

Travail à réaliser
  1. Créez un nouveau test en effectuant un clic droit sur le fichier de la classe « FloatCalculator » : PhpStorm create test
  2. Constatez que le nom de la classe de test ainsi que l'espace de noms sont directement tirés du nom de la classe à tester : PhpStorm create test details
  3. PhpStorm vous propose de suivre les modifications de ce nouveau fichier : PhpStorm create test git add
  4. Écrivez un premier test testOnePlusTwoEqualThree() qui vérifie que la méthode add() de la classe FloatCalculator retourne bien 3. lorsqu'elle reçoit 1. et 2..
    Remarque importante

    Toujours privilégier assertSame() par rapport à assertEquals() afin de contrôler le type en plus de la valeur

  5. Lancez votre premier test et corrigez les éventuelles erreurs 
    vendor/bin/phpunit --color tests/Calculator/FloatCalculatorTest.php 
PHPUnit 9.6.3 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.1.14
Configuration: /working/cutron01/dev/tests-phpunit/phpunit.xml

.                                                                   1 / 1 (100%)

Time: 00:00.006, Memory: 6.00 MB

OK (1 test, 1 assertion)
  6. Écrivez les tests de la méthode add() de la classe FloatCalculator : vous utiliserez des dataProvider pour vous permettre de fournir facilement plusieurs cas pour chaque méthode (combinez les cas limites comme 0, pensez au cas des nombres négatifs, aux parties décimales, …).
  7. Lancez vos tests et corrigez les éventuelles erreurs

Mise en place d'une « fixture » et suite des tests

À ce stade, vous avez dû remarquer que vous devez créer une nouvelle instance de « FloatCalculator » au début de chacun de vos tests. Ceci constitue la mise en place de chaque test qui devrait être partagée entre tous les tests à travers une « fixture ». Vous pourrez ensuite poursuivre l'écriture des tests de la classe.

Travail à réaliser
  1. Définissez une propriété protégée « floatCalculator » dans votre classe de test
  2. Initialisez la nouvelle propriété dans la méthode protégée « setUp() » qui sera automatiquement appelée avant chaque test par PHPUnit
  3. Modifiez le code des précédents tests pour faire usage de la « fixture » « floatCalculator »
  4. Écrivez les tests des autres méthodes de la classe FloatCalculator : n'oubliez pas de tester les cas qui lèvent des exceptions. Pour écrire les tests de la méthode sum(), vous devrez écrire un dataProvider dont le nombre d'arguments est variable et voir comment fournir cet argument variable à votre méthode sum().
  5. Lancez vos tests et corrigez les éventuelles erreurs
    Information

    Notez que les tests PHPUnit sont intégrés à PhpStorm. Vous pouvez les lancer par :

    • un clic droit sur le répertoire tests
    • un clic droit sur un fichier ou un onglet de fichier de test
    • un clic dans le code source d'un test
    • un clic sur les flèches vertes dans la marge du code source d'un test PhpStorm run test
    • le raccourci clavier « CTRL + SHIFT + F10 » qui lance la dernière configuration de tests
  6. Complétez vos tests avec des cas plus exotiques comme des modulos avec des réels, positifs et négatifs, des valeurs mettant au défit la précision des nombres réels, …

Prise en compte de la précision de la représentation des nombres en virgule flottante

Vous avez étudié la représentation des nombres en virgule flottante et vous savez que certains calculs conduisent nécessairement à un résultat approché. Peut-être que certains de vos tests vous ont déjà conduit à ce type de résultat. Dans tous les cas, vous allez introduire des valeurs impossibles à tester avec « assertSame() » et opter pour une solution adaptée à l'utilisation de nombres réels.

Travail à réaliser
  1. Ajoutez un cas de test dans le « dataProvider » associé aux tests de la méthode « modulus() » qui prouve que « 5. % 2.4 = 0.2 »
  2. Constatez que ce cas de test échoue avec le message : 
    Failed asserting that 0.20000000000000018 is identical to 0.2.
  3. Lisez la documentation de l'assertion « assertEqualsWithDelta() »
  4. Afin de gérer la précision (le delta de « assertEqualsWithDelta() ») de manière homogène et cohérente, définissez une constante « DELTA » dans la classe de test et fixez sa valeur à « 1E-15 »
  5. Modifiez toutes les utilisations de « assertSame() » en « assertEqualsWithDelta() »
    Information

    L'utilisation de « assertEqualsWithDelta() » est ici légitime et indispensable car vous travaillez avec des nombres réels codés en virgule flottante. Dans le cadre général, « assertSame() » reste bien évidement recommandé pour tester l'égalité de deux valeurs.

  6. Vérifiez que tous les tests passent

Doublures de test

Vous venez d'écrire des tests comparant le résultat attendu au résultat effectif de diverses méthodes. Ces méthodes étaient déterministes et non dépendantes de l'environnement, uniquement dépendantes des paramètres fournis.

Pour compliquer un peu la tâche et pousser plus avant votre connaissance des tests, vous allez écrire et tester la classe CurrentTime. Cette dernière donne la période de la journée en fonction de l'heure courante :

Résultat attendu de « getTimeOfDay() »
« getTimeOfDay() »
Heure débutHeure finRésutat
00:0005:59Night
06:0011:59Morning
12:0017:59Noon
18:0023:59Evening

« Mock objects »

Dans ces conditions, à moins de lancer les tests à des heures précises de la journée, il est impossible de vérifier le bon fonctionnement de la classe CurrentTime. Heureusement, vous avez accès aux doublures de tests et plus particulièrement, pour le cas qui nous intéresse, aux « mock objects » (ou objets fantaisie, ou encore objets factices).

Les « mock objects » permettent d'obtenir une doublure de test qui se comporte comme la classe mimée. Le comportement de certaines méthodes peut être simulé ou inspecté. La simulation du comportement de la méthode getTime() va permettre de « choisir l'heure donnée par la méthode getTime() » et donc, virtuellement, l'heure du test.

La classe aura donc la structure suivante : classe Time\InitialVersion\CurrentTime

Le diagramme précédent est celui de la classe Time\InitialVersion\CurrentTime.
Travail à réaliser
  1. Écrivez le squelette de la classe « Time\InitialVersion\CurrentTime » selon les spécifications données précédemment
  2. Écrivez la méthode getTime() qui retourne l'heure courante (de 0 à 23, sans les minutes) à partir de la fonction date() dont les options de formatage sont données dans la documentation de « DateTimeInterface::format() »
  3. Écrivez la méthode « getTimeOfDay() » qui retourne la chaîne de caractères « Night », « Morning », « Noon » ou « Evening » en fonction de l'heure donnée par « getTime() »
    Remarque importante

    Vous travaillez uniquement avec l'heure, pas avec les minutes.

  4. Générez la classe permettant de tester la classe « Time\InitialVersion\CurrentTime »
  5. Écrivez une méthode de test « testGetTimeBoundariesBetween0And23() » pour « getTime() » à partir d'une assertion « assertThat() » et de contraintes « PHPUnit\Framework\Constraint » permettant de vérifier la nature et les bornes de la valeur retournée
  6. Dans une méthode de test de la méthode « getTimeOfDay() », créez un « partial « mock » object » basé sur « Time\InitialVersion\CurrentTime » qui redéfinira la méthode « getTime() »
    Information

    Faute de documentation en ligne à jour, vous découvrez « createPartialMock() » d'après ce que nous dit la documentation du code source de PHPUnit : Vous vous baserez sur l'exemple de création d'un objet « mock » de la documentation et la manière de procéder pour fixer la valeur de retour d'une doublure de test.

  7. Modifiez le comportement de la méthode « getTime() » du « mock » partiel de « CurrentTime » afin qu'elle retourne « $time » qui sera un paramètre de la méthode de test
  8. Ajoutez un test qui vérifie que la méthode « getTime() » est appelée une seule fois
  9. Modifiez la méthode de test de « getTimeOfDay() » pour qu'elle accepte un « dataProvider » fournissant une série représentative de valeurs et les résultats attendus correspondants : 
    PHPUnit 9.6.3 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.1.14
Configuration: /working/cutron01/dev/tests-phpunit/phpunit.xml

Current Time (Tests\Time\InitialVersion\CurrentTime)
 ✔ Get time of day with time·set·to··0  2 ms
 ✔ Get time of day with time·set·to··3  1 ms
 ✔ Get time of day with time·set·to··5  1 ms
 ✔ Get time of day with time·set·to··6  1 ms
 ✔ Get time of day with time·set·to··8  1 ms
 ✔ Get time of day with time·set·to·11  1 ms
 ✔ Get time of day with time·set·to·12  1 ms
 ✔ Get time of day with time·set·to·14  1 ms
 ✔ Get time of day with time·set·to·17  1 ms
 ✔ Get time of day with time·set·to·18  1 ms
 ✔ Get time of day with time·set·to·21  1 ms
 ✔ Get time of day with time·set·to·23  1 ms
 ✔ Get time boundaries between 0 and 23  2 ms

Time: 203 ms, Memory: 12,00 MB

OK (13 tests, 29 assertions)

Modification de la conception pour rendre le système plus testable

En l'état, la méthode « getTimeOfDay() » est bien testée mais la méthode « getTime() » ne l'est pas vraiment. Vous avez simplement l'assurance qu'elle retourne une valeur entière comprise en 0 et 23 et cela dépend du moment où les tests sont exécutés. Vous allez refactoriser votre code afin de pouvoir tester la méthode « getTime() ». La conception est ici revue pour rendre le système testable.

La nouvelle classe « Time\TimestampVersion\CurrentTime » aura la définition suivante : classe Time\TimestampVersion\CurrentTime

Le diagramme précédent est celui de la classe Time\TimestampVersion\CurrentTime.
Travail à réaliser
  1. Copiez la classe « Time\InitialVersion\CurrentTime » en « Time\TimestampVersion\CurrentTime »
    Information

    Respectez le lien entre espace de noms et chemin de stockage du fichier.

  2. Générez une classe de test pour la nouvelle classe et recopiez-y les méthodes de la classe de test précédente
  3. Ajoutez une méthode « getTimestamp() » à votre classe « Time\TimestampVersion\CurrentTime » : Cette nouvelle méthode doit retourner le timestamp actuel
  4. Ajoutez un appel à la nouvelle méthode « getTimestamp() » en paramètre de « date() » dans « getTime() »
  5. Exécutez vos tests actuels qui doivent toujours être valides
  6. Maintenant que « getTime() » dépend du résultat de « getTimestamp() », vous pouvez écrire une méthode de test pour « getTime() »
  7. Dans cette nouvelle méthode de test, créez un « partial mock object » basé sur « Time\TimestampVersion\CurrentTime »
  8. Modifiez le comportement de la méthode « getTimestamp() » du « mock » partiel de « Time\TimestampVersion\CurrentTime » afin qu'elle retourne un timestamp nouvellement créé à partir de « strtotime("$time:00:00") » dans lequel « $time » sera un paramètre de la méthode de test
  9. Ajoutez un test qui vérifie que la méthode « getTimestamp() » est appelée une fois
  10. Modifiez la méthode de test de « getTime() » pour qu'elle accepte un « dataProvider » fournissant une série représentative de valeurs et les résultats attendus correspondants : 
    PHPUnit 9.6.3 by Sebastian Bergmann and contributors.

Configuration: /working/cutron01/tests-phpunit/phpunit.xml

Current Time (Tests\Time\TimestampVersion\CurrentTime)
 ✔ Get time of day with time·set·to··0  5 ms
 ✔ Get time of day with time·set·to··3  1 ms
 ✔ Get time of day with time·set·to··5  1 ms
 ✔ Get time of day with time·set·to··6  1 ms
 ✔ Get time of day with time·set·to··8  1 ms
 ✔ Get time of day with time·set·to·11  1 ms
 ✔ Get time of day with time·set·to·12  1 ms
 ✔ Get time of day with time·set·to·14  1 ms
 ✔ Get time of day with time·set·to·17  1 ms
 ✔ Get time of day with time·set·to·18  1 ms
 ✔ Get time of day with time·set·to·21  1 ms
 ✔ Get time of day with time·set·to·23  1 ms
 ✔ Get time boundaries between 0 and 23  1 ms
 ✔ Get time with time·set·to··0  1 ms
 ✔ Get time with time·set·to··3  1 ms
 ✔ Get time with time·set·to··6  1 ms
 ✔ Get time with time·set·to·12  1 ms
 ✔ Get time with time·set·to·23  1 ms

Time: 00:00.014, Memory: 6.00 MB

OK (18 tests, 39 assertions)

Fiabilisation par l'introduction de constantes

La fiabilité d'utilisation de la classe « Time\TimestampVersion\CurrentTime » peut être augmentée grâce au remplacement des chaînes de caractères retournées par « getTimeOfDay() » par des constantes de la classe. Ceci permettra d'éviter les erreurs de frappe difficilement détectables dans ces chaînes de caractères. Une erreur dans le nom de la constante de classe correspondante entraîne une erreur PHP qui met immédiatement le problème en évidence. Le problème sera même détecté avant l'exécution du code par votre IDE qui pointera une constante de classe non définie.

La nouvelle classe « Time\ConstantsVersion\CurrentTime » aura la définition suivante : classe Time\ConstantsVersion\CurrentTime

Le diagramme précédent est celui de la classe Time\ConstantsVersion\CurrentTime.
Travail à réaliser
  1. Copiez la classe « Time\TimestampVersion\CurrentTime » en « Time\ConstantsVersion\CurrentTime »
    Information

    Respectez le lien entre espace de noms et chemin de stockage du fichier.

  2. Générez une classe de test pour la nouvelle classe et recopiez-y les méthodes de la classe de test précédente
  3. Ajoutez les constantes à votre nouvelle classe
  4. Modifiez les méthodes de votre classe en conséquence
  5. Modifiez les tests en conséquence

« Stubs »

Dans une nouvelle version de la classe « CurrentTime », vous allez utiliser un objet DateTime pour gérer l'instant présent plustôt qu'un « timestamp » UNIX. Cette modification va impliquer une nouvelle façon d'aborder les tests par l'utilisation de « stubs » (ou bouchons)

La nouvelle classe « Time\DateTimeVersion\CurrentTime » aura la définition suivante : classe Time\DateTimeVersion\CurrentTime

Le diagramme précédent est celui de la classe Time\DateTimeVersion\CurrentTime.
Travail à réaliser
  1. Copiez la classe « Time\ConstantsVersion\CurrentTime » en « Time\DateTimeVersion\CurrentTime »
    Information

    Respectez le lien entre espace de noms et chemin de stockage du fichier.

  2. Générez une classe de test pour la nouvelle classe et recopiez-y les méthodes de la classe de test précédente
  3. Remplacez la méthode « getTimestamp() » par la méthode « getDateTime() » conformément au diagramme de classe précédent
  4. Modifiez le fonctionnement de la méthode « getTime() » en conséquence
  5. Modifiez le test de « getTimeOfDay() » pour que la méthode « getDateTime() » du « mock » de « Time\DateTimeVersion\CurrentTime » retourne un « stub » de « DateTime » pour lequel la méthode « format('H') » retourne « $time » (ce test, bien qu'amusant puis qu'il permet d'expérimenter « mock » et « stub », ne couvre que la méthode « getTimeOfDay() »)
  6. Modifiez le test de la méthode « getTime() » pour que la méthode « getDateTime() » du « mock » de « Time\DateTimeVersion\CurrentTime » retourne un objet « DateTime » dont l'heure est fixée à « $time »

Couverture de code

Afin d'évaluer la quantité de code testé, vous allez analyser la couverture de votre code. Vous lancerez l'analyse sur l'ensemble de vos tests avec un rapport sur l'ensemble de vous sources.

Remarque importante

Si vous travaillez sur votre ordinateur personnel, vous devez installer l'extension Xdebug.

Travail à réaliser
  1. Lancez le calcul du rapport de couverture de votre code au format texte
    Remarque importante

    Vous devrez fixer le mode de fonctionnement de Xdebug en préfixant votre commande de calcul de couverture de code par l'affectation de la variable d'environnement XDEBUG_MODE avec la valeur coverage : 

    XDEBUG_MODE=coverage vendor/bin/phpunit
  2. Observez les résultats et vérifiez que votre couverture de code est bien complète : 
    PHPUnit 9.6.3 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.1.14 with Xdebug 3.2.0
Configuration: /working/cutron01/dev/tests-phpunit/phpunit.xml

...............................................................  63 / 195 ( 32%)
............................................................... 126 / 195 ( 64%)
............................................................... 189 / 195 ( 96%)
......                                                          195 / 195 (100%)

Time: 00:00.661, Memory: 8.00 MB

OK (195 tests, 316 assertions)


Code Coverage Report:     
  2023-03-10 10:24:00     
                          
 Summary:                 
  Classes: 100.00% (8/8)  
  Methods: 100.00% (24/24)
  Lines:   100.00% (88/88)

Calculator\FloatCalculator
  Methods: 100.00% ( 6/ 6)   Lines: 100.00% ( 13/ 13)
Slug\Slugger
  Methods: 100.00% ( 1/ 1)   Lines: 100.00% ( 16/ 16)
Time\BackedEnumVersion\CurrentTime
  Methods: 100.00% ( 3/ 3)   Lines: 100.00% ( 10/ 10)
Time\ConstantsVersion\CurrentTime
  Methods: 100.00% ( 3/ 3)   Lines: 100.00% ( 10/ 10)
Time\DateTimeVersion\CurrentTime
  Methods: 100.00% ( 3/ 3)   Lines: 100.00% ( 10/ 10)
Time\EnumVersion\CurrentTime
  Methods: 100.00% ( 3/ 3)   Lines: 100.00% ( 10/ 10)
Time\InitialVersion\CurrentTime
  Methods: 100.00% ( 2/ 2)   Lines: 100.00% (  9/  9)
Time\TimestampVersion\CurrentTime
  Methods: 100.00% ( 3/ 3)   Lines: 100.00% ( 10/ 10)
    Information

    La couverture de code complète n'est pas le Graal, simplement le reflet de l'exécution de chacune des lignes de votre code lors des tests. Ceci ne signifie pas que votre code est testé, encore moins qu'il est valide. Pour ce sujet de TP, une couverture de code complète signifie que vous avez correctement réalisé toutes les questions.

  3. Lancer le calcul du rapport de couverture de votre code au format HTML dans un répertoire « coverage »
  4. Excluez de votre dépôt Git le répertoire « coverage » qui sera généré par PHPUnit
  5. Observez les résultats de couverture de code et corrigez ou terminez votre travail pour obtenir une couverture de code complète
  6. Ajoutez un nouveau script Composer « test:coverage » qui efface le répertoire « coverage » (récursivement et sans produire d'erreur s'il n'existe pas encore), avant de lancer la commande PHPUnit que vous venez d'élaborer
    Information

    À la suite de la commande d'évaluation de la couverture de code, vous pouvez ouvrir automatiquement le résultat « coverage/index.html » dans votre navigateur Web à l'aide d'une commande :

  7. Testez l'intégration de la couverture de code dans PhpStorm en effectuant un clic droit sur le répertoire « tests » et en sélectionnant « Run 'tests (PHPUnit)' with Coverage » phpstorm phpunit code coverage
  8. Observez les résultats d'analyse de couverture de code intégrés dans PhpStorm phpstorm phpunit code coverage