Les tests unitaires sur Magento 2 ont un réel intérêt qui mériterait certainement vos efforts pour les créer et les exécuter. Je vais énumérer ci-dessous quelques avantages importants de l’utilisation de tests unitaires.
De nombreux bugs sont trouvés au stade de la conception et de l’écriture du logiciel, de l’application, du site. L’écriture des tests unitaires empêche le passage de ces bugs aux étapes suivantes, y compris après la sortie du produit. Cela permet d’économiser les coûts de correction des bugs plus tard dans le cycle de vie du projet et apporte également des avantages aux utilisateurs finaux, à savoir d’utiliser un produit ergonomique, fonctionnel et sans bugs. Vous bénéficierez grandement d’une meilleure estimation du temps de test, économisant ainsi beaucoup de temps et de ressources.
Le principe est de fiabiliser le module pour qu’il fasse exactement ce qu’il est censé faire, et de tester que cela fonctionne bien. On écrit alors un test qui simule l’appel au module avec des données de test. On peut également utiliser des « mocks » pour simuler une base de données ou un webservice, afin de s’assurer que l’éventuelle erreur vient bien de notre code et non pas du service distant ou de la base de données qui serait momentanément indisponible.
Ainsi, tout au long de la vie du projet, les tests écrits permettent de valider que l’application fait toujours ce que l’on attend d’elle. Après chaque modification, avant chaque livraison, on relance les tests. Si l’un échoue, alors la modification d’une partie du code a entraîné des changements provoquant un résultat erroné. Il y a alors deux choix, soit le test doit évoluer car la fonctionnalité a évolué, soit le code modifié doit être revu et corrigé pour que le test continue de fonctionner. C’est une assurance de maintenir l’intégrité de l’application.
La méthode TDD (Test Driven Development): préconise d’écrire les tests unitaires avant d’écrire la moindre ligne de code source. Les points essentiels de la méthode sont :
- Écrire un test et vérifier qu’il échoue (le code qu’il teste n’existe pas encore, c’est donc normal).
- Écrire ensuite le code source pour que le test passe.
- Continuer à développer la fonctionnalité en s’assurant à chaque fois que le test est toujours fonctionnel.
Dans le monde de l’e-commerce, et notamment de Magento, il peut y avoir plusieurs raisons de mettre en place des tests unitaires. C’est d’ailleurs prévu par Magento 2 qui en parle dans sa documentation officielle.
Supposons un module qui affiche le prix d’un produit avec des réductions paramétrables. Supposons les règles suivantes:
- La réduction peut être soit un pourcentage, soit une remise fixe.
- La réduction ne peut pas être supérieure à 75% du prix de base.
La fonction dans le cas où la réduction serait une remise doit donc bien s’assurer que la remise fixe n’excède pas 75% du prix initial et si c’est le cas, la fonction doit bloquer la réduction à 75% (limitant ainsi la remise fixe).
On pourrait donc écrire le test unitaire qui vérifie cela : Le prix à payer est, au minimum, d’une valeur de 25% du prix initial. En mettant ce test en place, et pourquoi pas en amont du développement, on s’assure que la fonction qui sera écrite respectera bien à la lettre les règles établies. Ainsi, si dans plusieurs mois quelqu’un modifie la fonction, le test unitaire permettra de s’assurer que les modifications n’entraînent pas de régression fonctionnelle sur ce module.
Exécution de tests unitaires dans Magento 2 :
Étant donné que nous avons un module personnalisé nommé WebkulMarketplace sous l’espace de noms Override
(app/code/Override/WebkulMarketplace), nos tests unitaires résident dans le dossier Test/Unit selon les normes de dénomination.
La classe que nous allons tester s’appellera CustomerRegisterSuccessObserverTest et résidera dans le dossier Unit de sorte que le chemin complet serait: app/code/Override/WebkulMarketplace/Test/Unit/CustomerRegisterSuccessObserverTest.php
Notre code de classe ressemble à ceci:
Exécution de tests unitaires dans PhpStorm:
Il existe plusieurs façons d’exécuter le test PhpUnit:
- CLI
- Les commandes Magento
- Intégration IDE (PHPStorm)
Dans cette section, nous décrirons comment exécuter des tests unitaires sur PHPStorm.
Pour exécuter des tests unitaires sur PhpStorm, l’EDI doit d’abord être configuré. Il existe un fichier de configuration PHPUnit livré avec Magento 2
{ROOT} /dev/tests/unit/phpunit.xml.dist.
Le fichier de configuration indique à PHPUnit où trouver les cas de test à exécuter (avec d’autres informations). Pour le rendre actif, copiez le fichier dans le même dossier et supprimez l’extension .dist, de sorte que le nom est maintenant phpunit.xml.
Dans l’image ci-dessous, nous devons ajouter notre emplacement de test. Dans cet exemple, les autres emplacements de tests sont commentés car nous ne voulons pas que PHPUnit exécute tous les tests, juste celui que nous avons écrit précédemment.
Donc, notre phpunit.xml devrait ressembler à ceci :
Maintenant, PHPUnit peut trouver notre test. Pour configurer PHPStorm afin de pouvoir exécuter les tests, nous devons aller dans Toolbar > Run > Edit Configurations. Après l’apparition de la fenêtre contextuelle, nous cliquons sur le signe plus pour ajouter une nouvelle configuration.
Dans la liste déroulante, nous choisissons PHPUnit et sous la section Test Runner, nous choisissons Define in the configuration file et vérifions Use alternative configuration file et enfin sélectionnez le fichier phpunit.xml que nous avons édité précédemment.
Maintenant, PHPStorm connaît nos tests et est capable de les trouver. Il n’y a qu’une étape de plus pour terminer la configuration. PHPStorm doit également connaître l’emplacement de la bibliothèque PHPUnit et l’emplacement de l’interpréteur. Pour configurer cela, nous devons aller dans File > Settings > Languages & Frameworks > PHP > Test Frameworks. Dans cette section, nous voulons ajouter une nouvelle configuration en utilisant le symbole +.
En supposant que nous utilisons l’autoload de Composer, nous choisissons l’option Use Composer autoloader et sélectionner vendor/autoload.php.
Le chargeur automatique de Composer connaît l’emplacement de toutes les classes, donc la connexion de PHPStorm à autoload.php terminera la configuration de PHPStorm avec succès.
Pour effectuer notre test, nous pouvons cliquer sur l’icône Exécuter à côté des options de configuration dans le coin supérieur droit de PHPStorm. Le test doit réussir et notre console ressemble à ceci:
Conclusion:
Dans cet article, nous venons de gratter la surface des tests unitaires de Magento 2 et des tests unitaires en général. Ce sujet est très complexe et il n’est pas possible d’en couvrir beaucoup en un seul article. Je vous encourage donc à en savoir plus à ce sujet dans la documentation PHPUnit ou dans les tutoriels de test spécifiques à Magento 2. Les meilleurs exemples de test Magento 2 se trouvent naturellement dans le cœur de Magento.
Bon test