Tests avec PHPUnit

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

Si ce n'est pas déjà fait, installez Composer
Mettez Composer à jour
Si ce n'est pas déjà fait, relocalisez le cache de Composer

Information

Cette configuration est une nouvelle fois particulière à l'infrastructure de l'IUT. La modification du répertoire de cache de Composer n'est pas nécessaire sur votre ordinateur personnel.
Si ce n'est pas déjà fait, ajoutez un jeton d'authentification GitHub associé à Composer

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

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 []:

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",
    "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';

Constatez l'apparition du répertoire vendor
Vérifiez le contenu du fichier .gitignore afin de vous assurer que le répertoire vendor est bien exclu

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é.

Ajoutez les fichiers à l'index Git
```
git add .
```
Enregistrez les modifications dans le dépôt :
```
git commit
```
Poussez les modifications sur le dépôt distant :
```
git push
```
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

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 ».
Patientez pendant l'indexation des fichiers du projet visible dans la partie droite de la barre d'état

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

Recherchez le paquet de PHPUnit à l'aide de Composer :
```
composer search phpunit
```
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
```
Constatez l'apparition du répertoire « vendor/bin »
Observez le contenu du répertoire « vendor/bin »

Vérifiez que PHPUnit fonctionne :

vendor/bin/phpunit --version
PHPUnit 9.6.3 by Sebastian Bergmann and contributors.

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.

Passez l'option « forceCoversAnnotation » à « false »
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

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.
Référez-vous au sujet Installation et configuration de PhpStorm pour installer et configurer PHP CS Fixer
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

Référez-vous au sujet Installation et configuration de PhpStorm pour installer et configurer PHP Mess Detector
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

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]:

Placez le fichier de configuration de GrumPHP (télécharger) à la racine de votre projet
Observez les tâches du fichier de configuration fourni et lisez la documentation associée à chacune d'entre elles

Afin de vérifier le bon fonctionnement de GrumPHP :

Supprimez la description de votre projet dans « composer.json »
Ajoutez le fichier « composer.json » à l'index Git :
```
git add composer.json
```

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

Si le test de commit n'a pas déclenché GrumPHP, initialisez-le dans votre projet avec :
```
vendor/bin/grumphp git:init
```
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
```
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). Une déconnexion/reconnexion est nécessaire pour que les modifications soient prises en 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

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

Vérifiez que la version de PHP indiquée dans PhpStorm soit la bonne
Vérifiez que les modèles de PhpStorm intègrent le typage strict
Configurez les outils d'analyse statique / de tests statiques de code PHP
Créez les répertoires src et tests :
```
mkdir src tests
```
Lisez la documentation de Composer sur l'auto-chargement PSR-4
Ouvrez le fichier composer.json
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)
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/

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 :

Le diagramme précédent est celui de la classe « Slug\Slugger ».

Travail à réaliser

Lancez la création d'une nouvelle classe dans le répertoire « src » avec PhpStorm :
Nommez cette nouvelle classe Slugger dans le namespace Slug :
PhpStorm vous propose de suivre les modifications de ce nouveau fichier :
Écrivez le squelette de la classe « Slug\Slugger » selon les spécifications fournies dans le diagramme de classe
Placez le fichier de tests SluggerTest.php (télécharger) dans le répertoire tests/Slug

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.

Réalisez la méthode slugify() qui transforme un texte, généralement HTML, en une étiquette répondant aux contraintes suivantes :
- les balises HTML doivent être supprimées
- les entités HTML doivent être traduites en caractères
- seuls les caractères alphanumériques ASCII sont autorisés (une translittération 'Any-Latin; Latin-ASCII' sera nécessaire)
  
  Remarque importante
  
  Sur votre ordinateur personnel, vous devez activer le module intl de PHP pour avoir accès à la fonction « transliterator_transliterate() ».
- toute série de caractères autres qu'alphanumériques ASCII est remplacé par un tiret, il ne peut y avoir deux tirets consécutifs ou plus (voir le fonctionnement des expressions rationnelles)
- il ne peut y avoir de tiret en début ou fin d'étiquette
- le texte de l'étiquette est mis en minuscules avant translittération en ASCII ou après translittération en ASCII (pas de gestion de UTF-8)

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 :

Le diagramme précédent est celui de la classe Calculator\FloatCalculator.

Travail à réaliser

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

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;
    }

Observez les informations fournies par PHP CS Fixer et PHP Mess Detector qui provoquent le soulignement du code problématique :
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 :
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 :
Constatez les modifications apportées à la mise en forme du code
Une fois le fichier corrigé automatiquement par PHP CS Fixer, des erreurs mises en évidence par PHP Mess Detector subsistent :
Placez-vous sur la variable $a et appuyez sur SHIFT + F6 pour renommer la variable en $firstOperand :
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
Renommez le paramètre $b de la même façon
É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

Créez un nouveau test en effectuant un clic droit sur le fichier de la classe « FloatCalculator » :
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 vous propose de suivre les modifications de ce nouveau fichier :
É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

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)

É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, …).
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

Définissez une propriété protégée « floatCalculator » dans votre classe de test
Initialisez la nouvelle propriété dans la méthode protégée « setUp() » qui sera automatiquement appelée avant chaque test par PHPUnit
Modifiez le code des précédents tests pour faire usage de la « fixture » « floatCalculator »
É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().
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
- le raccourci clavier « CTRL + SHIFT + F10 » qui lance la dernière configuration de tests
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éfi 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

Ajoutez un cas de test dans le « dataProvider » associé aux tests de la méthode « modulus() » qui prouve que « 5. % 2.4 = 0.2 »

Constatez que ce cas de test échoue avec le message :

Failed asserting that 0.20000000000000018 is identical to 0.2.

Lisez la documentation de l'assertion « assertEqualsWithDelta() »
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 »
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.
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ébut	Heure fin	Résutat
00:00	05:59	`Night`
06:00	11:59	`Morning`
12:00	17:59	`Noon`
18:00	23:59	`Evening`

« 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 :

Le diagramme précédent est celui de la classe Time\InitialVersion\CurrentTime.

Travail à réaliser

Écrivez le squelette de la classe « Time\InitialVersion\CurrentTime » selon les spécifications données précédemment
É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() »
É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.
Générez la classe permettant de tester la classe « Time\InitialVersion\CurrentTime »
É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
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.
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
Ajoutez un test qui vérifie que la méthode « getTime() » est appelée une seule fois

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 :

Le diagramme précédent est celui de la classe Time\TimestampVersion\CurrentTime.

Travail à réaliser

Copiez la classe « Time\InitialVersion\CurrentTime » en « Time\TimestampVersion\CurrentTime »

Information

Respectez le lien entre espace de noms et chemin de stockage du fichier.
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
Ajoutez une méthode « getTimestamp() » à votre classe « Time\TimestampVersion\CurrentTime » : Cette nouvelle méthode doit retourner le timestamp actuel
Ajoutez un appel à la nouvelle méthode « getTimestamp() » en paramètre de « date() » dans « getTime() »
Exécutez vos tests actuels qui doivent toujours être valides
Maintenant que « getTime() » dépend du résultat de « getTimestamp() », vous pouvez écrire une méthode de test pour « getTime() »
Dans cette nouvelle méthode de test, créez un « partial mock object » basé sur « Time\TimestampVersion\CurrentTime »
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
Ajoutez un test qui vérifie que la méthode « getTimestamp() » est appelée une fois

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 :

Le diagramme précédent est celui de la classe Time\ConstantsVersion\CurrentTime.

Travail à réaliser

Copiez la classe « Time\TimestampVersion\CurrentTime » en « Time\ConstantsVersion\CurrentTime »

Information

Respectez le lien entre espace de noms et chemin de stockage du fichier.
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
Ajoutez les constantes à votre nouvelle classe
Modifiez les méthodes de votre classe en conséquence
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 :

Le diagramme précédent est celui de la classe Time\DateTimeVersion\CurrentTime.

Travail à réaliser

Copiez la classe « Time\ConstantsVersion\CurrentTime » en « Time\DateTimeVersion\CurrentTime »

Information

Respectez le lien entre espace de noms et chemin de stockage du fichier.
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
Remplacez la méthode « getTimestamp() » par la méthode « getDateTime() » conformément au diagramme de classe précédent
Modifiez le fonctionnement de la méthode « getTime() » en conséquence
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('G') » retourne « $time » (ce test, bien qu'amusant puis qu'il permet d'expérimenter « mock » et « stub », ne couvre que la méthode « getTimeOfDay() »)
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

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
```
Cherchez les options de la commande phpunit permettant d'obtenir un rapport de couverture de code sous forme de texte

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.

Lancer le calcul du rapport de couverture de votre code au format HTML dans un répertoire « coverage »
Excluez de votre dépôt Git le répertoire « coverage » qui sera généré par PHPUnit
Observez les résultats de couverture de code et corrigez ou terminez votre travail pour obtenir une couverture de code complète
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 :
- xdg-open sur Linux
- start sur Windows
- open sur macOS
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 »
Observez les résultats d'analyse de couverture de code intégrés dans PhpStorm

Objectifs de la séance ¶

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

En fin de séance ¶

En début de séance ¶

Versionnage du projet ¶

Initialisation du dépôt ¶

Consignes ¶

Installer et configurer Composer ¶

Initialiser le projet Composer ¶

Création du projet dans PhpStorm ¶

Installation des outils de qualité de code ¶

PHPUnit ¶

PHP CS Fixer ¶

PHP Mess Detector ¶

GrumPHP ¶

Scripts Composer ¶

Configuration du projet ¶

Développement guidé par les tests, un exemple ¶

Premiers tests et (re)découverte de PhpStorm ¶

Définition d'une classe « FloatCalculator » ¶

Définition de la classe de test ¶

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

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

Doublures de test ¶

« Mock objects » ¶

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

Fiabilisation par l'introduction de constantes ¶

« Stubs » ¶

Couverture de code ¶

Installer et configurer `Composer` ¶

Initialiser le projet `Composer` ¶

Création du projet dans `PhpStorm` ¶

`PHPUnit` ¶

`PHP CS Fixer` ¶

`PHP Mess Detector` ¶

`GrumPHP` ¶

Scripts `Composer` ¶

Premiers tests et (re)découverte de `PhpStorm` ¶

Définition d'une classe « `FloatCalculator` » ¶