Testing

Résumé coaching 8

PAR GROUPE
+ Le groupe présente bien, sur le wiki, la stratégie de testing mise en place : Quels tests (unitaire, intégration, API, end2end, …) et pourquoi?  
+ Tous les étudiants comprennent les différences entre les types de tests utilisés

+ Les étudiants ont mis en place au moins des tests unitaires
+ Les étudiants indiquent s'ils ont mis d'autres types de tests en place : tests d'intégration, d'API, End2End et montre des exempes
+ Sur le wiki, le groupe présente le choix de l'outil pour chaque type de tests
+ Le groupe indique ce qu'ils ont utilisé comme DB pour leurs tests (autre que production?)

INDIVIDUEL
+ Chaque étudiant a mis des tests unitaires en oeuvre pour son US personnelle (ou une autre au besoin, en concertation avec le coach).   
+ Chaque étudiant a écrit sur le wiki un bilan des tests qu'il a réalisés, sur base d'un rapport de testing et de son interprétation, avec le code coverage.
+ Chaque étudiant a réfléchi aux valeurs d'input à utiliser pour les tests, et présente cette analyse dans la page "Tests" du wiki, notamment en fournissant un tableau valeurs d'input/résultat attendu
+ Les tests sont intéressants, couvrent bien l'US et passent.  L'étudiant est capable de les expliquer. 

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

[A indiquer :

• l'outil de test
• le nombre de test,
• le code coverage
• la méthodologie pour le choix des valeurs d'input,
• les tableaux input/output utilisés pour construire les tests
• si possible la couverture des tests concernés.
• Le lien vers le code des tests en question
• si cela est relevant, l'étudiant qui a mis en place le système permettant d'effectuer les tests. ]

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

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

[Idem]

3. Rapport de test et interprétation

4. Tests individuels (a priori pour US personnelles)

4.1 Etudiant 1

[Bilan personnel de la réalisation des tests, ce que l'étudiant a testé.]

[Lien vers le code de test produit par l'étudiant]

[Nombre de tests réalisés, avec des Tableaux de valeurs input/output utilisés pour comprendre la philosophie des tests]

4.2 Etudiant 2

4.3 Etudiant 3

4.4 Etudiant 4