Testing

1. Présentation globale des tests

[Méthodologie globale, liste des types de test (unitaire, intégration, ...), et pour chacun, quelle technologie de test a été utilisée + justification]

2. Tests effectués

2.1 Tests unitaires : Outils et Bilan

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.

Problèmes rencontrés

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

1. 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.
2. 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.
3. Manque de compétences spécifiques : Une méconnaissance des meilleures pratiques de testing pour TypeScript et Solid JS a également limité notre efficacité.

Solutions proposées pour les projets futurs :

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.

2.2 Tests d'intégration et Tests d'API : Outils et Bilan

Branche Test API

Outils Utilisés

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 et changements apportés

1. API Utilisateurs

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 champ password_hash.
• Lors de la suppression d'un utilisateur (DELETE /api/users/:id), une erreur de contrainte de clé étrangère sur la table user_info empêchait la suppression.

Changements apportés :

• Ajout de la vérification et de la récupération du password_hash existant 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.

---

2. API Enterprises

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.

---

3. API Applications

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.

---

4. API Schedules

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.

---

Bilan

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.

2.3 Tests end-to-end : Bilan

Environnement de Test

• URL de base : /login
• Navigateur : Cypress Test Runner

Scénarios de Test

1. 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".
   • 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.

2. 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 passe 8u27eackw1.
     • Cliquer sur le bouton "Se connecter".
     • Vérifier que l'URL contient /adverts.
     • Vérifier la présence de l'élément h1 avec le texte "Adverts".
   • Résultat Attendu : Après la connexion, l'utilisateur doit être redirigé vers /adverts et le titre "Adverts" doit être visible.

3. 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 h1 avec le texte "Adverts".
     • Vérifier que les cartes des annonces (.adv-card) sont présentes et en nombre supérieur à 0.
   • 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.

3. Rapport de test et interprétation

3.1 Synthèse des Résultats

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.

3.2 Interprétation

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.

4. Tests individuels (a priori pour US personnelles)

4.1 Delcroix Brice

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.

4.2 Detilleux Bruno (US2.1)

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. Le problème étant que les librairies de tests ne savent pas être utilisées pour faire des tests sur des objets ayant des dépendances d'état. 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 notre composant intermédiaire pour définir le type d'utilisateur et ainsi appliquer des conditions diverses sur des fonctionnalités du code :

Par faute de temps nous n'avons pas pu continuer à chercher des solutions pour remédier à nos problèmes liés à nos test unitaires.

4.3 Etudiant 3

4.4 Etudiant 4