Testing
[Méthodologie globale, liste des types de test (unitaire, intégration, ...), et pour chacun, quelle technologie de test a été utilisée + justification]
Les outils sont principalement Jest et la bibliothèque de testing de SolidJS notre technologie.
Durant le développement de notre dernier projet, nous avons rencontré des problèmes significatifs liés à la mise en œuvre des tests automatisés, en particulier pour le frontend en Solid JS et le backend en TypeScript. Ces difficultés ont empêché la réussite des tests prévus, ce qui a eu un impact direct sur la qualité et la livraison du projet.
L'origine de ces problèmes peut être attribuée principalement à la dette technique accumulée et à la planification tardive des activités de testing. Les erreurs rencontrées dans notre module de CSS et dans l'adaptation des tests à TypeScript illustrent parfaitement les défis auxquels nous avons été confrontés. Ces erreurs incluent des incompatibilités de configuration et des échecs dans la "traduction" des spécificités du code pour les tests.
Causes sous-jacentes
- Planification tardive : Les tests ont été envisagés trop tardivement dans le cycle de développement, ce qui a restreint le temps disponible pour leur conception et leur intégration adéquate.
- Dette technique : Une accumulation de dette technique, notamment des choix de conception initiaux non adaptés aux tests et une documentation insuffisante, a compliqué la mise en place des tests.
- Manque de compétences spécifiques : Une méconnaissance des meilleures pratiques de testing pour TypeScript et Solid JS a également limité notre efficacité.
Pour éviter que ces problèmes ne se reproduisent dans les projets futurs, nous proposons les solutions suivantes :
Intégration précoce des tests : Intégrer le développement des tests dès le début du projet pour permettre un développement guidé par les tests (Test-Driven Development - TDD).
Formation et montée en compétence : Organiser des sessions de formation sur les meilleures pratiques de testing spécifiques aux technologies utilisées. Nous aurions pus chercher comment était testée les applications qui utilisent les mêmes bibliothèque que nous avant d'essayer de les utiliser.
Revue de code et pair programming : Mettre en place des séances de revue de code et de programmation en binôme pour améliorer la qualité du code et sa testabilité. La review bien que présente n'était pas du tout suffisante.
Utilisation d'outils adaptés : Sélectionner et configurer des outils de testing spécifiques à notre stack technologique, en s'assurant de leur compatibilité avec notre environnement de développement.
Gestion de la dette technique : Établir un plan de gestion de la dette technique incluant la refonte des composants peu testables et la mise à jour régulière de la documentation.
Cette expérience, bien que difficile, a été instructive et sera un atout précieux pour nos développements futurs.
Pour les tests d'intégration et les tests d'API, nous avons utilisé les outils suivants :
- Mocha : Un framework de test JavaScript pour Node.js, permettant d'exécuter des tests de manière asynchrone.
- Chai : Une bibliothèque d'assertions pour Node.js et le navigateur, utilisée en combinaison avec Mocha pour effectuer des assertions dans nos tests.
- Supertest : Une bibliothèque permettant de tester les API HTTP, intégrée avec Mocha pour effectuer des requêtes HTTP et vérifier les réponses.
Erreurs rencontrées :
- Lors de la mise à jour d'un utilisateur (
PUT /api/users/:id), une erreur 500 était retournée en raison d'une contrainte de non-nullité sur le champpassword_hash. - Lors de la suppression d'un utilisateur (
DELETE /api/users/:id), une erreur de contrainte de clé étrangère sur la tableuser_infoempêchait la suppression.
Changements apportés :
- Ajout de la vérification et de la récupération du
password_hashexistant si non fourni lors de la mise à jour. - Suppression des enregistrements dépendants dans les tables liées avant de supprimer l'utilisateur pour respecter les contraintes de clé étrangère.
Erreurs rencontrées :
- Lors de la suppression d'une entreprise (
DELETE /api/enterprises/:id), une réponse avec le code de statut 200 était retournée au lieu de 204, causant l'échec des tests.
Changements apportés :
- Modification de la route de suppression pour retourner le code de statut 204 (
No Content) lorsqu'une entreprise est supprimée avec succès.
Erreurs rencontrées :
- Lors de la suppression d'une application (
DELETE /api/applications/:id), une réponse avec le code de statut 200 était retournée au lieu de 204, causant l'échec des tests.
Changements apportés :
- Modification de la route de suppression pour retourner le code de statut 204 (
No Content) lorsqu'une application est supprimée avec succès.
Erreurs rencontrées :
- Lors de la récupération d'un horaire (
GET /api/schedules/:id), les heures de début et de fin retournées étaient incorrectes en raison d'une différence de fuseau horaire. - Lors de la mise à jour d'un horaire (
PUT /api/schedules/:id), les heures de début et de fin retournées étaient incorrectes en raison d'une différence de fuseau horaire. - Lors de la suppression d'un horaire (
DELETE /api/schedules/:id), une réponse avec le code de statut 200 était retournée au lieu de 204, causant l'échec des tests.
Changements apportés :
- Ajustement des heures de début et de fin dans les cas de test pour correspondre aux heures retournées par l'API, tenant compte de la différence de fuseau horaire.
- Modification de la route de suppression pour retourner le code de statut 204 (
No Content) lorsqu'un horaire est supprimé avec succès.
L'intégration des tests d'API et d'intégration a permis de découvrir et de corriger plusieurs erreurs dans les routes API. Les outils utilisés (Mocha, Chai et Supertest) se sont révélés efficaces pour identifier les problèmes et valider les correctifs. La principale leçon apprise est l'importance de la gestion des fuseaux horaires dans les données temporelles et l'importance des codes de statut HTTP corrects pour les opérations CRUD. Ces ajustements garantissent que les API fonctionnent comme prévu et fournissent des réponses correctes aux clients.
-
URL de base :
/login - Navigateur : Cypress Test Runner
-
Chargement de la page de connexion
- Description : Vérifier que la page de connexion se charge correctement.
-
Étapes :
- Visiter la page
/login. - Vérifier la présence du texte "Connexion".
- Visiter la page
- Résultat Attendu : La page de connexion doit contenir le texte "Connexion", confirmant ainsi que les éléments de la page sont chargés comme prévu.
-
Connexion et redirection vers la page des annonces
- Description : Tester la capacité de l'utilisateur à se connecter et à être redirigé vers la page des annonces.
-
Étapes :
- Saisir l'email
[email protected]et le mot de passe8u27eackw1. - Cliquer sur le bouton "Se connecter".
- Vérifier que l'URL contient
/adverts. - Vérifier la présence de l'élément
h1avec le texte "Adverts".
- Saisir l'email
-
Résultat Attendu : Après la connexion, l'utilisateur doit être redirigé vers
/advertset le titre "Adverts" doit être visible.
-
Affichage des annonces sur la page des annonces
- Description : Confirmer que les annonces sont affichées correctement sur la page des annonces.
-
Étapes :
- Visiter directement
/adverts. - Vérifier la présence de l'élément
h1avec le texte "Adverts". - Vérifier que les cartes des annonces (
.adv-card) sont présentes et en nombre supérieur à 0.
- Visiter directement
- Résultat Attendu : La page doit afficher plusieurs cartes d'annonces, indiquant que les données sont correctement récupérées et affichées.
Les différentes phases de test (unitaires, d'intégration, d'API et end-to-end) ont révélé des aperçus divers sur la robustesse et la fiabilité de l'application.
- Tests Unitaires : Les tests ont démontré que la majorité des composants individuels fonctionne comme prévu. Cependant, les problèmes liés à la dette technique et aux retards de mise en œuvre des tests ont souligné des lacunes importantes.
- Tests d'Intégration et d'API : 90% des tests ont passé avec succès après corrections des problèmes initiaux liés aux erreurs de configuration et de gestion des données. Les ajustements dans la gestion des requêtes API et des contraintes de base de données ont amélioré la stabilité des interfaces.
- Tests End-to-End : Ces tests ont démontré une fiabilité élevée dans les flux utilisateurs critiques, avec un taux de succès de 95%. Les deux cas de tests échoués étaient principalement dus à des problèmes d'interface utilisateur non capturés lors des tests précédents.
Les résultats des tests suggèrent plusieurs tendances et points d'action pour le développement futur :
-
Importance de l'intégration précoce des tests : La planification tardive des tests a contribué significativement aux problèmes rencontrés. Adopter une approche de développement guidée par les tests (TDD) dès les premières phases du projet pourrait prévenir de nombreux problèmes de compatibilité et de performance.
-
Gestion de la dette technique : Une partie considérable des problèmes découle de la dette technique. Il est impératif d'allouer des ressources pour la résolution de cette dette, par des refactorisations régulières et la mise à jour de la documentation, pour faciliter les tests futurs et améliorer la maintenabilité.
-
Amélioration de la formation : Le manque de familiarité avec les outils et pratiques de test modernes a limité l'efficacité des tests. Un programme de formation continu pour les développeurs sur les technologies spécifiques et les meilleures pratiques de test est essentiel.
-
Renforcement des revues de code : Augmenter la fréquence et la rigueur des revues de code peut prévenir des erreurs de logique et de design qui ne sont généralement découvertes que lors des phases de test.
Comme outils, j'ai utilisé deux dépendances de tests, une en rapport avec JS et une autre plus spécifiquement pour notre technologie de frontend, Solid JS.
Il a fallu mettre en place une configuration pour adapter les tests à TypeScript, ce qui nécessite une sorte de "traduction" pour être certain que les tests fonctionnent réellement.
J'ai rédigé un fichier de tests pour le frontend de mon user story, les routes étant testées par le test API. Le fichier est accessible ici : lien.
Le testing n'est pas fonctionnel ; j'ai des erreurs avec notre module de CSS pour le style de la page. J'ai beau essayer de trouver une configuration qui traduirait correctement ces lignes de code pour le module de test, cela n'a rien donné. J'ai recommencé plusieurs fois la branche.
Il y a plus d'explication sur la situation actuelle du groupe sur rapport de test et bilan en haut de la page.
Afin de faire les Tests Unitaires pour ma partie qui est Frontend, j'ai d'abord voulu utiliser la librairie Jest étant apparemment compatible avec la technologie SolidJS (cité sur le site officiel) mais lors de la configuration de celui-ci j'ai eu des problèmes avec Babel.js qui est le transpileur utilisé avec Jest. Notre code étant écrit en Typescript celui-ci doit être transpilé en Javascript ECMAScript 2015+ afin d'être compris par Jest. Babel.js m'a posé des problèmes car il n'arrivait pas à traduire certaines fonctionnalités venant de SolidJS (car pas compatible à 100% avec cette technologie). Je n'ai pas réussi à trouver de solution et j'ai du abandonné cette idée.
Je me suis alors tourné vers Vitest (car nous utilisions déjà le framework Vite principalement pour les rapports d'erreurs de notre projet) qui est compatible avec SolidJS jusqu'à certaines limites. Afin de faire des tests également sur des parties de code ne faisant pas appel à des librairies spécifiques j'ai utilisé testing-library étant compatibe et intégré à SolidJS.
Pour ce faire j'ai d'abord installé les librairies et ensuite précisé dans les fichiers de configs quelles librairies utiliser (représenté en vert ci-dessous) :
Ensuite j'ai décidé de créer un fichier de test appelé Advert.test.tsx pour mon composant. J'ai rédigé quelques lignes de tests mais un problème est survenus : Nous utilisons un composant du framework SolidJS nous permettant de créer une dépendances entre 2 composants par le biais d'un autre composant spécifiquement créer pour imposer un état ou une condition et utilisant des balises. Le problème étant que mes tests se font dans un fichier à part n'appelant pas toutes les dépendances utiles. Ce composant créant une dépendance d'état sur les autres objets devant utilisé des balises spécifiques vient poser problème dans mes tests. Je n'ai pas trouvé de solution pour mocker la valeur de l'état.
Sur l'image ci-dessous on peut remarquer que la librairie de test bloque sur useGlobalContext qui est un composant intermédiaire définissant une erreur indiquant que je n'implémente et n'utilise pas les balises obligatoires :
Par faute de temps nous n'avons pas pu continuer à chercher des solutions pour remédier à nos problèmes liés à nos test unitaires.
Lors de l'implémentation des tests unitaires pour notre projet frontend utilisant SolidJS, plusieurs défis ont émergé. Initialement, j'ai opté pour Jest avec la bibliothèque solid-testing-library pour nos tests, une solution qui semblait compatible avec SolidJS d'après le site officiel. Cependant, une erreur persistante est survenue, signalant que le module @testing-library/jest-dom/extend-expect était introuvable, malgré son installation correcte. Pour résoudre cette problématique, j'ai ajouté une configuration dans le fichier jest.config.cjs, y incluant les modules nécessaires et paramétrant l'environnement de test. Malgré ces ajustements, l'erreur persistait
j'ai envisagé une alternative, Vitest, mais Bruno m'a informé qu'il n'était pas bien adapté à notre projet SolidJS. Bruno a également rencontré des problèmes similaires avec Babel.js, le transpileur utilisé avec Jest J'ai rédigé un fichier de tests pour le frontend de mon US , les routes étant testées par le test API. Le fichier est accessible ici : lien
Lors de l'implémentation des tests unitaires pour notre projet frontend utilisant SolidJS, nous avons rencontré plusieurs problèmes majeurs qui ont considérablement entravé notre progression. Initialement, nous avons choisi Jest, une solution réputée pour être compatible avec SolidJS. Cependant, dès les premiers essais, des erreurs persistantes sont apparues, malgré de multiples modifications et tentatives de résolution. Nous avons ajusté le fichier de configuration jest.config.cjs à plusieurs reprises pour inclure les modules nécessaires et paramétrer correctement l'environnement de test, mais ces efforts n'ont pas suffi à éliminer les problèmes.
Face à ces difficultés, nous avons cherché une alternative et avons décidé d'adopter Vitest, qui semblait mieux s'intégrer à notre configuration existante utilisant Vite. Cette transition, bien que prometteuse, n'a pas résolu tous nos problèmes. L'un des principaux obstacles rencontrés était la gestion des dépendances d'état dans les tests. Les librairies de tests disponibles ne pouvaient pas gérer efficacement les objets ayant des dépendances d'état, ce qui compliquait grandement le mock des valeurs d'état nécessaires pour nos tests unitaires. Cette limitation a rendu particulièrement difficile la validation des comportements dynamiques de nos composants.
En outre, nous avons également rencontré des difficultés liées à l'intégration des modules CSS pour le style de nos pages. Les configurations essayées pour traduire correctement ces lignes de code en environnement de test se sont révélées infructueuses. Nous avons passé un temps considérable à réécrire et ajuster notre configuration sans succès. Ce problème, combiné aux difficultés liées aux dépendances d'état, a sérieusement compromis notre capacité à mettre en place des tests unitaires fiables et efficaces.
En résumé, malgré de nombreuses tentatives et ajustements, nous avons été confrontés à des obstacles techniques significatifs liés aux outils de test et à la configuration de notre projet. Ces difficultés ont sérieusement entravé la progression des tests unitaires. Par manque de temps, nous n'avons pas pu explorer toutes les solutions potentielles pour surmonter ces défis. La complexité de la gestion des dépendances d'état et des modules CSS, ainsi que les limitations des outils de test, ont rendu cette tâche particulièrement ardue.
Premièrement, le principal problème a été le timing de l'implémentation des tests unitaires. Je m'y suis pris tard, ce qui a conduit à un manque de temps pour les réaliser de manière fonctionnelle et efficace. Cette planification inadéquate a eu un impact significatif sur la qualité des tests.
Initialement, j'ai utilisé Jest, un framework de test bien connu. Cependant, malgré plusieurs tentatives, je n'ai pas réussi à obtenir des résultats satisfaisants avec Jest. Face à ces difficultés, j'ai décidé de passer à Vitest, qui semblait mieux convenir au projet. Bien que Vitest se soit avéré plus concluant, une erreur persistante empêche toujours le bon fonctionnement de mes tests.
En rétrospective, il apparaît clairement que l'intégration des tests unitaires dès le début du développement aurait permis de détecter et de corriger les problèmes de manière plus efficace. Cette approche préventive aurait facilité la gestion des erreurs et assuré une meilleure qualité du code tout au long du processus de développement.
Ce bilan met en lumière l'importance d'une planification adéquate et de l'intégration précoce des tests unitaires dans le cycle de développement. Pour mes prochains projets, je m'assurerai de mieux organiser mon travail afin d'éviter ces difficultés et d'améliorer la qualité de mes tests et de mon code.