Pour 202 ecommerce, comme pour tous les acteurs du développement informatique, réaliser des solutions stables pour ses clients est une bataille de tous les jours.
Tant que nous travaillons en tant qu’agence, c’est à dire dans le contexte spécifique d’un marchand, les différents tests à réaliser sont parfaitement connus et leur nombre est limité.
Mais dès lors que nous réalisons des modules destinés à tous les marchands PrestaShop, le nombre de tests à réaliser explose : différentes versions de PrestaShop, différentes versions de PHP/MySQL, contexte d’utilisations spécifiques, etc… Il devient donc nécessaire de réfléchir à la manière de tester, et d’automatiser le plus de contrôle qualité possible.
La fin programmée des tests manuels ?
Depuis une dizaine d’années, différentes technologies de tests automatisés se sont développées, et certains noms reviennent en boucle dans les dîners mondains (de geeks), à tel point qu’on pourrait imaginer que plus personne ne teste manuellement !
C’est bien sûr exagéré, les tests humains restent nécessaires, mais le principe est, comme dans bien d’autres domaines, d’utiliser l’informatique pour préparer le travail, et « rentabiliser » au maximum le temps de cerveau humain.
En parallèle, il s’agit d’intégrer des tests le plus tôt possible dans la chaîne de développement, et ainsi éviter d’attendre la fin d’une réalisation complexe pour découvrir qu’un de ses composants ne fonctionne pas correctement.
Test unitaires et tests d’intégration
Le test unitaire consiste à tester individuellement chaque composant d’un code informatique.
Le test d’intégration consiste à tester le bon fonctionnement des différents composants entre eux.
Par exemple, si vous réalisez une calculatrice :
– Un test unitaire consiste à tester l’addition en injectant directement 1 + 2 au composant qui gère les additions, et vérifier que le résultat est 3.
– Un test d’intégration consiste à tester l’addition en tapant sur les touches 1 + 2 = puis en vérifiant que le résultat affiché à l’écran est 3.
Le second test valide différents composants simultanément : le clavier, le composant qui gère les additions et l’écran. Mais si le test échoue, comment savoir quel composant ne fonctionne pas correctement ? Si le résultat est 4, c’est peut être le clavier qui envoie 2 quelque soit la touche sur laquelle on appuie !
Cette exemple illustre parfaitement le besoin de réaliser les deux familles de tests : unitaire pendant le développement des différents composants, puis intégration une fois les différents composants disponibles.
Les deux familles de test peuvent être automatisés, mais automatiser un test d’intégration est plus compliqué : pour réaliser le test d’intégration de l’exemple, il serait nécessaire de simuler des clics sur les boutons de la calculatrice, puis lire le résultat dessiné sur l’écran de la calculatrice. Ainsi les tests d’intégration restent généralement manuels.
Les tests unitaires : tout le monde en parle, si peu le font
La plupart des développeurs ne sont plus à convaincre sur la nécessité et l’efficacité de coder tout en réalisant des tests unitaires, mais encore faut-il le faire !
En effet, réaliser les tests unitaires nécessite de changer sa méthode de travail et demande plus de rigueur. De plus, bien que faisant partie des bonne pratiques, on trouve peu de documentation ou d’outils.
Il suffit de taper dans Google « tests unitaires PrestaShop » pour constater que les solutions sont minces. Bien qu’un embryon de test unitaires soit apparu avec PrestaShop 1.7, il n’existe aucune solution couvrant toutes les versions et permettant des tests complets, officielle, ou de la communauté PrestaShop.
ll y a encore 6 mois, nos tests étaient quasiment exclusivement humains, et tous au niveau tests d’intégration. Cela nécessitait beaucoup de temps sans être garant d’un 100% qualité.
Nous avons mis en place un outillage complet, et adapté nos méthodes de développement, pour introduire des tests unitaires et / ou de non-régression. Il a notamment été nécessaire de supporter les versions antérieures à PrestaShop 1.7 , et de simuler le contexte (ce dernier point a été ajouté en 1.7.3, mais nos modules devant être rétrocompatibles, nos tests doivent l’être aussi !).
Docker : un allié de poids
Pour l’automatisation des tests, il est nécessaire de mettre en place une chaîne de traitement qui va au delà du test unitaire en lui même. Par exemple : comment tester différentes version de PHP comme évoqué plus haut ?
Un des composant essentiel de notre chaine de développement est Docker, qui permet de réaliser des tests à la fois humains et PHPUnit dans un environnement virtualisé, qui peut être créé à la demande.
Ce premier article sur nos choix technologiques internes sera suivi d’autres contenus qui viendront enrichir notre section Lab. Nous partagerons aussi certains outils de la chaîne décrite ci-dessus. Suivez-vous ou abonnez-vous à notre newsletter !