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]

Les tests unitaires ont été principalement utilisés pour vérifier le bon fonctionnement de chaque composant et fonction de l'application indépendamment. Pour cela, on l'a fait avec Jest parce qu'il est facile de l'intégrer avec React, simple pour l'écriture des tests et on sait réaliser le code Coverage.

2. Tests effectués

2.1 Tests unitaires : Outils et Bilan

• L'outils de test : Jest (avec babel pour traduire le tsx/jsx)
• Nombre de test : 1 fichier de test par fichier (fichier intéressant à tester) + min 1 fichier de test unitaire par US
• code coverage :
• Méthodo pour les valeurs d'inputs : Mock de notre base de données et copies des valeurs présente (pomme, banane, etc.) avec bien sur des requêtes vides, - avec n'importe quoi dedans, etc.
• Tableau input/ output : Voir dans la section test
• couverture des tests : Voir dans la section test
• liens vers les codes de test : Voir dans la section test
• étudiant qui à mis en place le système pour les test : Ann-Lore, Antoine, Théo, Thomas

[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

• L'outils de test : Jest
• Nombre de test : Bonne question
• code coverage :
• Méthodo pour les valeurs d'inputs : Tester tout les résultats possibles pour les routes implémentées
• Tableau input/ output :
• couverture des tests :
• liens vers les codes de test :
• étudiant qui à mis en place le système pour les test : Antoine

2.3 Tests end-to-end : Bilan

• L'outil de test : Cypress (tests end-to-end simulant l’expérience utilisateur réelle dans le navigateur)
• Nombre de tests : Bonne question mais on lira pas ça.
• Code coverage : non mesuré automatiquement, mais couverture fonctionnelle étendue via interactions DOM ; possibilité d’ajout via cypress-coverage si besoin
• Méthodologie pour les valeurs d'input :
• Tableaux input/output : Voir dans la section test
• Couverture des tests : Tous les scénarios utilisateurs principaux sont testés. Possibilité de compléter avec des tests de navigation.
• Lien vers les codes de test : Voir dans la section test
• Étudiant qui a mis en place le système de test : Ann-Lore

3. Rapport de test et interprétation

Après exécution de l’ensemble des tests (unitaires, intégration, API et end-to-end), nous avons pu obtenir des résultats significatifs en termes de robustesse et de couverture du code.

4. Tests individuels (a priori pour US personnelles)

4.1 Etudiant 1 /Ann-Lore Schoonyans

Bilan personnel : Des tests unitaires ont été mis en place pour US1-Lister les produits en stock. Ces tests vérifient des fonctions pour mettre le statut du produit ainsi que sa date de livraison. Il y a 12 tests unitaires qui ont été développés dans le fichier frontend/app/inventaire/models. Les tests d'intégrations (7 tests) appellent des fonctions (jest.Mock) et vérifient si cela donne le résultat attendu. Il y a aussi des tests vérifiant sur la page web si les éléments apparaissent correctement (6 tests). Il y a un test End to End qui teste le comportement d'un ajout de produit fait avec Cypress. A partir du coverage, on peut voir qu'il y a encore des améliorations à faire ainsi que de créer plus de tests pour mieux couvrir le code. Pour le fichier ProductService, celui-ci n'est pas du tout couvert car ses fonctions servent uniquement à récupérer des données via des appels API et ne contiennent pas de logique métier.

Les fichiers sont dans :

Tests unitaires

Tests d'intégration

Test End to End

Tests d'interface : filtre

Tests d'interface : liste produit

4.2 Etudiant 2 /Théo Cahuzac

Bilan personnel :
Mise en place de tests unitaires et test d'intégration. Les 2 types de test sont assez simple mais fonctionne pour vérifier le bon fonctionnement du code.

Les test d'intégration portent sur Header.tsx et SearchResults.tsx alors que les test unitaires portent sur une fonction de SearchResults.tsx que j'ai amener vers un autre fichier du nom de filterProducts.tsx

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

• SearchResults.test.tsx
• Header.test.tsx
• filterProducts.tsx

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

4.3 Etudiant 3 / Antoine Bontems

Bilan personnel : Les tests permettent de valider toutes les actions limites de l'utilisateur et de vérifier que le comportement est bien celui attendu

Lien vers les tests du panier

PASS app/cart/cartClient.test.jsx √ directly changes quantity using input field (13 ms) √ prevents quantity from exceeding stock (99 ms)
√ shows alert when exceeding stock manually (24 ms)
√ updates total dynamically when quantities change (16 ms)
√ renders correctly when cart becomes empty (41 ms)
Cart component
√ renders all items with correct quantities and total (113 ms)
√ increases quantity when + button is clicked (23 ms)
√ decreases quantity when - button is clicked (18 ms)
√ removes item from cart when quantity is 0 and user confirms (19 ms)
√ does not remove item if user cancels the confirm dialog (15 ms)

4.4 Etudiant 4 / Thomas Girboux

Bilan personnel :

Les tests unitaires valident minutieusement les fonctions métier clés : mise à jour immuable des données dans updateFormData, validation complète des mots de passe et gestion des réponses API dans submitRegistration (réussites, erreurs 400, parsing, pannes réseau). Les tests d’intégration, avec useRouter().push mocké, confirment l’affichage des erreurs de saisie, le blocage en cas d’email invalide, l’appel correct à l’API et le traitement des messages d’erreur serveur. Cette approche mixte garantit une suite rapide, stable et maintenable.

hhttps://github.com/ZosiscoIV/Dev-Web-2024/blob/Thomas_US401_test_et_secu/frontend/app/register/page.test.tsx

[Nombre de tests réalisés, avec des Tableaux de valeurs input/output utilisés pour comprendre la philosophie des tests] Test d'unité sur des diffrenetes fonctions: