Testing
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. [Méthodologie globale, liste des types de test (unitaire, intégration, ...), et pour chacun, quelle technologie de test a été utilisée + justification]
[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. ]
Implémentation de Vitest
[Idem]
[Idem]
[Bilan personnel de la réalisation des tests, ce que l'étudiant a testé.]
J'ai réalisé des tests du côté des administrateurs (managers du club) sur la liste des utilisateurs. Ces tests visent à vérifier que les utilisateurs s'inscrivent correctement et que leurs informations s'affichent conformément aux paramètres saisis. J'ai également effectué une vérification de la modification du profil administrateur. Mon objectif était de m'assurer que les champs permettant d'introduire les nouvelles données sont bien présents dans le document, ainsi que le bouton permettant d'enregistrer les modifications.
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] Nous avons choisi d'utiliser Vitest pour effectuer nos tests car nous développons notre projet avec Vite. Vitest s'intègre parfaitement avec Vite, offrant une configuration rapide et une expérience de test cohérente et efficace, ce qui optimise notre flux de travail.
J'ai mise en place différent test pour mon US personnelle correspondant à l'agenda.
Du côté administrateur et utilisateur je vérifie si j'ai bien récupéré le rendu du composant <Liste_evenement />.
Ensuite, du côté administrateur, J'ai vérifier si le formulaire pour rajouter des évènement existait bien. Enfin j'ai vérifié ci les erreurs ce génèrent bien en cas de mauvais submit du formulaire.
voici un screen de tous les modules importé pour effectuer correctement du component Agenda.Data.jsx du côté Admin.
Et voici les Tests du côté admin:
le code n'as pas encore été push sur le repository principale de notre projet Liens vers mon code