Testing - Tablify-Developement/Tablify-Web GitHub Wiki
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
Notre stratégie de tests repose sur plusieurs niveaux de vérification :
| Type de test | Objectif | Outil utilisé |
|---|---|---|
| Tests unitaires | Valider les fonctions/services isolés | Jest + Supertest |
| Tests d’intégration | Vérifier les routes API avec la base de données | Supertest + PostgreSQL dockerisé |
| Tests end-to-end | Scénarios utilisateurs complets (non réalisés) | Non mis en œuvre |
Nous avons choisi Jest pour sa simplicité d’utilisation avec Node.js et son intégration avec TypeScript.
2. Tests effectués
2.1 Tests unitaires : Outils et Bilan
- Framework : Jest
- Fichiers testés :
reservationController.ts,reservationModel.ts - Couverture estimée :
- Statements : ~65 %
- Functions : ~60 %
- Branches : ~50 %
Méthodologie
- Tests sur flux principaux et flux d’erreur
- Vérification des valeurs limites et comportements en cas d’erreur
- Validation des méthodes statiques et règles du modèle
| Cas de test | Input | Output attendu |
|---|---|---|
| Création de réservation valide | infos réservation valides | 201 + objet réservation |
| Conflit réservation (même créneau) | tableId déjà réservé | 409 + message d’erreur |
| Mauvais restaurantId/tableId | ID inexistant | 404 |
| Création sans données requises | données manquantes | 400 |
📎 *Lien vers les tests de reservation
2.2 Tests d’intégration et d’API
- Outil : Supertest
- Base de données : PostgreSQL locale dans un conteneur Docker (db de test dédiée)
- Routes testées :
- POST /api/reservations
- GET /api/reservations/:id
- DELETE /api/reservations/:id
2.3 Tests end-to-end
Pas réalisés pour ce projet, faute de temps et de besoin prioritaire.
3. Rapport de test et interprétation
- Les tests couvrent les cas critiques de la gestion des réservations
- Bon niveau de fiabilité sur la logique métier (modèle + contrôleur)
- Quelques tests complémentaires à ajouter sur les erreurs serveur internes
- La couverture reste à augmenter sur les contrôleurs secondaires (utilisateurs, horaires…)
4. Tests individuels
4.1 Noah Rogier
| Cas de test | Input | Output attendu |
|---|---|---|
| Réservation d’une table libre | données valides | 201 + objet réservation |
| Conflit sur une table déjà réservée | tableId déjà pris à la même heure | 409 + message "Table déjà réservée" |
| Création avec mauvais ID de restaurant/table | ID inexistant | 404 + message "Not found" |
| Validation du schéma reservationModel | création avec données invalides | Erreur de validation mongoose |
- Nombre de tests réalisés : 10+
- Fichiers concernés :
reservationController.ts,reservationModel.ts - Tests réalisés dans
backend/tests/reservation.test.ts
📎 Branche GitHub : testUnitaire_reservation
4.2 Étudiant 2
(à compléter)
4.3 Étudiant 3
(à compléter)
4.4 Étudiant 4
(à compléter)
✅ Le projet inclut des tests unitaires et d’API robustes couvrant les cas les plus courants
🧪 Des améliorations futures pourront porter sur les tests end-to-end et l’augmentation de la couverture sur les contrôleurs