Le mix de tests logiciels de cloudtec pour les plateformes en ligne

Dans l’article précédent, nous avons décrit les types de tests qui existent et pourquoi le bon mix dépend du projet. Un site web demande une autre combinaison qu’une application web ou une plateforme en ligne. Passons au concret : voici le mix que nous utilisons dans notre propre logiciel.

Pourquoi nous testons

Nos plateformes sont développées et enrichies en continu. C’est précisément ce qui rend les tests nécessaires : non pas prouver une fois que quelque chose fonctionne, mais prouver que cela fonctionne encore après la prochaine modification. Quatre points nous tiennent à cœur :

• Éviter les régressions. Un nouveau code ne casse pas des fonctions existantes sans que personne ne s’en aperçoive.
• Sécuriser les mises à jour. Après des mises à jour importantes du framework ou de modules, il est prouvé que l’application fonctionne toujours.
• Permettre le refactoring. Qui veut restructurer du code a besoin d’un filet. Sans tests, le code obsolète reste en place, parce que personne n’ose y toucher.
• Prouver la qualité. Chaque build doit réussir tous les tests avant qu’une release n’ait lieu.

À quoi nous mesurons un bon test

Tous les tests ne justifient pas l’effort qu’ils demandent. Nous nous tenons à quatre critères :

• Résistant au refactoring. Le test continue de passer lorsque le code est restructuré. Il ne doit échouer que si le comportement de la fonction change réellement.
• Vite écrit, vite exécuté. Plus un test demande d’effort à développer, plus il y a de chances qu’il ne voie jamais le jour.
• Une couverture de code élevée, c’est-à-dire une part élevée de lignes de code qu’une exécution de test parcourt et valide réellement.
• Précis. Les faux positifs et les faux négatifs coûtent plus de temps qu’ils n’en font gagner. Nous renonçons aux tests sur du code non pertinent.

Les quatre types de tests dans nos plateformes

Behat : workflows et autorisations dans le navigateur

Les tests Behat pilotent un vrai navigateur et couvrent ainsi l’interface utilisateur, JavaScript compris. Ils sont plus lents que tous les autres types de tests, mais offrent en contrepartie la meilleure couverture de code et résistent le mieux au refactoring. Nous les utilisons pour reproduire les workflows au sein d’une plateforme et jouer des scénarios avec des données de test. Ils servent aussi à vérifier les autorisations : le test contrôle que les contenus et les ressources ne sont visibles que pour les personnes autorisées.

Tests de modules : des composants isolés face au framework

Les tests de modules, aussi appelés feature tests, simulent le framework Symfony et vérifient des classes isolées : une commande, un modèle de courriel, un event listener. Ils résistent moins bien au refactoring que les tests Behat, mais s’écrivent plus vite et obligent à un code proprement découpé.

Un exemple : un listener écrit une entrée d’historique dès qu’un élément configuré est créé ou mis à jour. Behat vérifie dans l’interface si l’entrée apparaît. Le test de module passe en revue toutes les combinaisons possibles et s’assure que le listener se déclenche aussi lorsqu’une entité est mise à jour via une commande, donc sans aucune interface.

Tests unitaires : une logique autonome

Nous utilisons les tests unitaires là où un bout de code est autonome et n’accède pas à d’autres interfaces ou fonctions. Ils s’exécutent rapidement et sont les plus simples à créer. Un cas typique est le calcul des prix dans notre module e-commerce : les fonctions se calculent de manière isolée, sans navigateur ni base de données.

Smoke tests : la plateforme démarre-t-elle seulement ?

Avant le déploiement d’une nouvelle application, les smoke tests vérifient que les fonctions et les services sont présents comme prévu. Chez nous, il s’agit surtout de smoke tests de routes : le test appelle chaque route disponible et contrôle qu’un statut 200 est renvoyé.

Le second usage concerne nos plateformes intranet à structure modulaire. Pour chaque projet, on définit quels modules sont actifs. Les smoke tests garantissent qu’une instance nouvellement installée fonctionne dans chaque combinaison de modules, y compris avec des modules désactivés.

Ce que cela signifie pour votre projet

Vous obtenez des plateformes qui fonctionnent de manière fiable, et pas seulement le jour de la mise en production. Les tests nécessaires se décident projet par projet : nous sécurisons d’abord les processus critiques pour l’activité, tout le reste suit le rapport entre effort et bénéfice.

Nous vous impliquons directement dans la phase de test. Personne ne connaît mieux les exigences métier que les personnes qui travaillent avec au quotidien.