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
Test sur la globalité total des endpoints API
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 Thomas
J'ai choisi de me concentrer sur les tests liés au gameplay ainsi qu'aux transactions, car c'est principalement sur ces aspects que j'ai travaillé au cours du projet. Étant donné leur nature concrète, la mise en place des tests s'est révélée relativement simple.
Lien vers le code de test
| Input |
Output attendu |
Objectif |
| user_id = 1 |
Liste d'utilisateurs sans user_id = 1, avec beers = 7 |
Vérifier l'exclusion du joueur actuel |
| get_user_beer_reserve(uid=1) → 7 |
Tous les autres joueurs ont beers = 7 |
Vérifier appel à la fonction de réserve |
| Input |
Output attendu |
Objectif |
| winner_id = 2, loser_id = 1, beers = 5 |
{"success": True, "message": "Transaction completed"} |
Valider la réussite de la transaction |
| has_enough_beer(uid=1, beers=5) → 1 |
|
Vérifier que le loser a assez de bières |
| how_many_beer(uid=1) → 10, how_many_beer(uid=2) → 5 |
|
Vérifier la mise à jour correcte des stocks |
| Appels à do_beer_transaction et add_transaction |
|
Vérifier les appels aux procédures de BDD |
| Input |
Output attendu |
Objectif |
| winner_id = 2, loser_id = 1, beers = 5 |
Exception HTTP 405, message : "n'a plus assez de bieres" |
Vérifier blocage si bières insuffisantes chez le perdant |
| has_enough_beer(uid=1, beers=5) → 0 |
|
|
4.3 Tristan
Je me suis concentré sur les tests liés à la gestion des utilisateurs : création, connexion, gestion des amis et réinitialisation de mot de passe. Ces tests permettent de garantir la robustesse des interactions utilisateur avec la base de données, notamment en simulant divers scénarios (utilisateur existant, mot de passe incorrect, erreur base de données, etc.).
Récupération des utilisateurs
| Input |
Output attendu |
Objectif |
call_function → [{"username": "user1"}, {"username": "user2"}] |
Liste contenant "user1" |
Vérifier le retour de la fonction get_all_users |
Récupération de l’e-mail
| Input |
Output attendu |
Objectif |
username = "user1" |
"[email protected]" |
Vérifier la récupération correcte de l’e-mail |
username invalide |
None |
Vérifier le cas d’un utilisateur inexistant |
email = None |
Exception |
Vérifier la gestion d’un input invalide |
Réinitialisation du mot de passe
| Input |
Output attendu |
Objectif |
| utilisateur existant + token actif |
Message indiquant qu’une demande existe déjà |
Tester un cas déjà traité |
| utilisateur inexistant |
Message d’erreur |
Vérifier la gestion d’un email inconnu |
email = None |
Exception |
Vérifier la validation des entrées |
Création d’un utilisateur
| Input |
Output attendu |
Objectif |
username inexistant |
Succès + appel à la procédure |
Vérifier la création d’un nouvel utilisateur |
username existant |
Exception "existe déjà" |
Empêcher la duplication |
Erreur dans call_procedure |
Exception "Procedure error" |
Gérer une erreur base de données |
Connexion utilisateur
| Input |
Output attendu |
Objectif |
bon username + bon mot de passe |
Message "connexion réussie" |
Valider le fonctionnement de login |
bon username + mauvais mot de passe |
Exception |
Refuser la connexion |
| utilisateur inexistant |
Exception |
Gérer l’erreur d’utilisateur inconnu |
Gestion des amis
| Input |
Output attendu |
Objectif |
add_friend(1, 2) |
Succès + appel procédure add_friend |
Ajouter un ami s’ils ne sont pas encore amis |
add_friend déjà amis |
Exception |
Empêcher les doublons |
add_friend(1, 1) |
Exception |
Empêcher de s’ajouter soi-même |
delete_friend(1, 2) |
Succès + appel procédure delete_friend |
Supprimer un ami |
delete_friend sans lien |
Exception |
Gérer le cas d’amis non existants |
delete_friend(1, 1) |
Exception |
Empêcher de se supprimer soi-même |
Gestion des erreurs de base de données
| Input |
Output attendu |
Objectif |
call_function → Exception "DB error" |
Exception levée |
Gérer une erreur générique sur appel fonction |
call_procedure → Exception "Procedure error" |
Exception levée |
Gérer une erreur générique sur procédure |
4.4 Etudiant 4