Tests unitaires avec PHPunit

Par Alexandre, le 23/08/2019 à 14h14 dans DevOps

Pourquoi fait-on des test unitaires ? Pour ne pas avoir de surprise lors de la mise en production. L outil PHPunit 6.3 compatible avec Symfony4.
Les assertions définissent le nombre de test. On peut sortir les tests sous format html et voir d’après le graphique si nos tests couvrent l’ensemble de l application ou pas. Le rapport de couverture de code donne une indication concernant les lignes exécutées par les tests automatisés lancés par PHPUnit.

L’ecriture du test est une tâche que l’on fait à la fin sauf si on veut faire du TDD (Test Driven Developpement) c'est-à-dire écrire les tests avant l’écriture du code. Un test unitaire est dit boîte blanche car il requiert d'avoir lu (donc de connaître) le code testé, contrairement à un test fonctionnel qui lui est dit boîte noire (il n'est pas nécessaire de connaître le code testé dans le détail.

Quand on souhaite écrire des test, la classe à étendre est \PHPUnit_Framework_TestCase. Elle nous donne accès entre autres aux méthodes permettant d'effectuer des assertions. Les noms des classes de test et des méthodes répondent à des conventions de nommage.

On appelle Dummy un objet testé. On l’élève au rang de Stub pour lui indiquer un comportement attendu. Et on l’appelle Mock ou doublure si on lui passe des attentes ou expectations en anglais comme le type attendu. Il faut prendre garde à ne pas utiliser les mocks pour tout dans un test au risque de ne plus tester quoi que ce soit. Un mock ne peut être utilisé que pour remplir un contrat concernant le type d'un objet nécessaire lors de l'instanciation d'une classe à tester par exemple. Les méthodes à implémenter avant ou après un test PHPUnit afin d'exécuter du code sont les méthodes setUp et tearDown. Pour les mocks d’objets on peut aussi utiliser Prophecy.