Testing - dudleydehenau/ScapeGame 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

[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

[Idem]

2.3 Tests end-to-end : Bilan

[Idem]

3. Rapport de test et interprétation

4. Tests individuels (a priori pour US personnelles)

Delcorte Maxime

Je me suis occupé des tests pour le login, le signup et les commentaires. Pour mes tests d'api, j'ai testé pour les différentes routes :
- commentaire : -- vérification de le présence de l'en-tête authorization pour delete -- vérification de le présence de l'en-tête authorization pour create -- vérification de le présence de l'en-tête authorization pour fetch -- si cela est ok , je vérifie si mes routes fonctionnes
- login : -- vérification de le présence de l'en-tête authorization -- vérification si l'utilisateur existe dans le base de donnée -- vérification de mot de passe -- si ok , je vérifie si ma route fonctionne
- signup : -- vérification de la création d'un utilisateur

https://github.com/dudleydehenau/ScapeGame/blob/main/backend/auth.spec.js

INPUT	OUTPUT
Login : (email: [email protected],userPassword: password123)	should log in a user and return 200 status
Login : (email: [email protected], userPassword: password123) => valeur qui n'existe pas dans la DB	should return 401 status if user does not exist
Login : (email: [email protected] ,userPassword: password), => mot de passe incorrect	should return 401 status if password is incorrect
signup : ( userFName: "test",userLName: "test",userBirth: "1990-01-01",email: "[email protected]",userPassword: "password123")	should return 201 status if user is created
Commentaire fetch: sans authorization	should return 401 status if no authorization for fetch
Commentaire create : sans authorization	should return 401 status if no authorization for create
Commentaire delete : sans auhtorization	should return 401 status if no authorization for delete
Commentaire fetch ; avec authorization	should return 200 status if authorization for fetch is provided
Commentaire create ; avec authorization => levelId: 1, userId: 1,commentaryText: "test pour le test"	should return 201 status if authorization for create is provided
Commentaire delete ; avec authorization	should return 200 status if authorization for delete is provided

Scalais Florian

Je me suis occupé des tests unitaires pour mon jeu et pour la page de lancement du jeu. J'ai aussi un test d'intégration qui appelle la méthode addScore du service ScoreService => test l'intégration entre le composant et le service.

INPUT	OUTPUT
submitCode : codeInput = '9532'	codeCorrect est vrai, calculateScore et addScoreToDatabase sont appelés.
submitCode : codeInput = '1234'	codeCorrect est faux, "Code incorrect. Rien ne se passe..." est dans journalEntries, timer est augmenté.
closeSafeInterface : codeInput = '9532', showCodeInterface = true	codeInput est '', showCodeInterface est faux.
calculateScore (intégration avec ScoreService) : codeInput = '9532', timer = 100, codeCorrect = true	mockScoreService.addScore est appelé avec (1, 1, 100).
ngOnInit	timerInterval est défini.
Initialisation (test du timer)	timer est 0 au départ, puis > 0 après 1500 ms.
Test de l'initialisation du formulaire	form est défini, commentaryText est défini, invalide.
Test de la validation du champ commentaryText vide ou trop court : commentaryText vide, commentaryText = 'short'	form est invalide dans les deux cas.
Test de la validation du formulaire avec données valides : commentaryText = 'This is a valid comment.'	form est valide.
delete (appel du service et mise à jour des commentaires) : id = 1	mockCommentaireService.deleteCommentaire est appelé avec 1, component.fetchAll est appelé.

Dudley De Henau

Swagger Output

Je me suis occupé des tests pour les routes d'API définies dans le fichier Swagger pour les fonctionnalités liées aux scores.

Scores

Create Score :
- Vérification de la présence de l'en-tête authorization.
- Vérification du statut de réponse approprié.
Fetch Best Score :
- Vérification de la présence de l'en-tête authorization.
- Vérification du statut de réponse approprié.
Update Score :
- Vérification de la présence de l'en-tête authorization.
- Vérification du statut de réponse approprié.

INPUT	OUTPUT
POST /score/scores : (levelId: 1, userId: 1, scoreBTime: "120")	should create a score and return 201 status
GET /scores/best/{userId}/{levelId} : avec authorization (userId: 1, levelId: 1)	should return the best score for the user and level, 200 status
PUT /scores/update : (levelId: 1, userId: 1, score: 150) => mise à jour d'un score existant	should update the score and return 201 status
POST /scores/ : (levelId: 2, userId: 2, scoreBTime: "100") => ajout sans autorisation	should return 401 status if no authorization is provided
GET /scores/best/{userId}/{levelId} : sans authorization (userId: 2, levelId: 2)	should return 401 status if no authorization is provided
PUT /scores/update : (levelId: 2, userId: 2, score: 200) => mise à jour sans autorisation	should return 401 status if no authorization is provided

Score Test Component

Je me suis occupé des tests unitaires pour les fonctionnalités du composant Score. Pour mes tests unitaires, j'ai testé les différentes méthodes :

Score Component : Création

Vérification de la création du composant.

Méthodes

getScore() :
- Vérification que la méthode retourne la liste des scores.
- Vérification que la méthode appelle l'API get pour récupérer les scores.
addScore(score: any) :
- Vérification que la méthode ajoute un score à la liste.
- Vérification que la méthode appelle l'API post pour ajouter un nouveau score.
deleteScore(scoreId: number) :
- Vérification que la méthode supprime un score de la liste.
- Vérification que la méthode appelle l'API delete pour supprimer un score.

INPUT	OUTPUT
getScore() : appels API pour récupérer les scores	should return the list of scores
addScore(score: any) : ajout d'un score	should add a score and return success response
deleteScore(scoreId: number) : suppression d'un score	should delete a score and return success response

RPG Game Component

Je me suis occupé des tests unitaires pour les fonctionnalités du composant RPG Game. Pour mes tests unitaires, j'ai testé les différentes méthodes :

RPG Game Component : Création

Vérification de la création du composant.

Méthodes

startGame() :
- Vérification que la méthode initialise correctement le jeu.
- Vérification que la méthode appelle l'API pour récupérer les données nécessaires au jeu.
playTurn(action: string) :
- Vérification que la méthode exécute l'action de jeu spécifiée.
- Vérification que la méthode met à jour l'état du jeu en fonction de l'action.
endGame() :
- Vérification que la méthode termine le jeu et affiche les résultats.
- Vérification que la méthode appelle l'API pour sauvegarder les résultats du jeu.

INPUT	OUTPUT
startGame() : initialisation du jeu	should initialize the game and set the required data
playTurn(action: string) : action de jeu	should perform the specified game action and update the state
endGame() : terminaison du jeu	should end the game and save the results

Patrycja Drewnowska

Je me suis occupé des tests pour le jeux château. Etant donné qu'il y a beaucoup de fonctions pour le jeux château je n'ai pas su faire des tests sur tous, j'ai tester le component mapChateau, PieceSecrete et scoreFin. Il y a des tests sur le frontend et sur l'api que j'ai créée 'classement'

voici les tests pour le component scoreFin, il y a principalement des tests sur les api utilisées pour envoyer et récupérer les scores dans la base de donnée:

INPUT	OUTPUT
submitScore() : est appeler avec ngOnInit()	submitScore devrait être appelé
submitScore() : soumet le score avec le levelId, le userId et le totalScore	devrait envoyer levelId, userId et totalScore
getBestScore() : récupère le meilleur score pour levelId et userId actuel	devrait récupérer le meilleur score pour levelId et userId actuel
getClassement() : récupère le classement pour levelId	devrais récupérer le classement pour levelId
formatClassement() : créer le classement pour afficher le meilleur score et les scores des autres utilisateurs	devrait créer le classement pour afficher le meilleur score et les scores des autres utilisateurs

Voici les tests pour le component PieceSecrete:

INPUT	OUTPUT
flamePorte() : change l'état de la flamme de la porte	devrait changer l'état de la flamme de la porte
cartes() : change l'état des cartes	devrait changer l'état des cartes
craneTable() : change l'image du crâne et met à jour le code	devrait changer l'image du crâne et mettre à jour le code
validerCodePorte() : valide le code de la porte avec 'mauvais code'	devrait mettre sur false 'flameCouloir' et reset crane image and flamePorteOn
validerCodePorte() : validation du code de la porte avec 'le bon code'	devrait ouvrir la porte et calculer le score total
sortirChateau() : affiche l'écran de score du joueur	devrait afficher l'écran de score du joueur

Voici les tests pour le component mapChateau:

INPUT	OUTPUT
cle() : change l'état de 'coffreOn'	devrait changer l'état de 'coffreOn' à true
tableDroite() : devrais changer l'image du crane sur la table à droite	devrait changer l'état de 'craneTableDroiteOn'
monstreGauche() : appelle la fonction	devrait mettre à true 'osGauche'
monstreDroit() : appelle la fonction	devrait mettre à true 'osDroit'

Tran Thi Tony

Je me suis occupé des tests unitaires de mes fonctionnalités càd celle du trie, du filtre et de la barre de recherche. on vas commencer avec le filtre :

INPUT	OUTPUT
Appel HTTP GET à http://localhost:3000/level/data	renvoie un tableau de jeux fictifs filtrer
Méthode component.filterGames() appelée	retourne expected spy updateFilterGames/updateLevelData to have been called si il y a une erreur

voici maintenant la barre de recherche :

INPUT	OUTPUT
Devrait créer le composant	expect(component).toBeTruthy(); passe si le composant est créé correctement.
Click sur le bouton avec la classe .loupe	expect(component.search).toHaveBeenCalled(); passe si search est appelé.
component.searchTerm = 'ch'; component.updateSuggestions();	expect(component.suggestions).toEqual(['chambre', 'chateau']); passe si les suggestions sont mises à jour correctement.
component.selectSuggestion('prison');	expect(component.searchTerm).toEqual('prison'); et expect(component.suggestions).toEqual([]); passent si searchTerm et les suggestions sont mises à jour correctement.
component.searchTerm = 'prison'; component.search();	expect(levelService.searchLevels).toHaveBeenCalledWith('prison'); passe si searchLevels est appelé avec le bon terme de recherche.
component.goToLevel({ levelId: 1, levelName: 'prison' });	expect((component as any).router.navigate).toHaveBeenCalledWith(['/game', 'prison']); passe si la navigation vers la route correcte est effectuée.

pour finir le trie

INPUT	OUTPUT
Devrait créer le composant	component est défini (vrai)
component.tri('option1');	levelService.updateLevelData est appelé
component.tri('option2');	levelService.updateLevelData est appelé
component.tri('option3');	levelService.updateLevelData est appelé