Mise à jour des TPs

web/docs/03-tps/01-Correction.md

@@ -3,6 +3,10 @@
 ## Pondération
 Chaque TP représente 20% de la note final
 
+TODO:
+- Pas de tests pour le TP1
+
+
 ## Évaluation du projet (Évaluation d’équipe)
 ### Fonctionnalités /10 – 5%
 Le projet est excellent.
@@ -141,22 +145,22 @@ o	L’application à corriger (client ou backend), votre application pourrait ê
 Pour la remise individuelle
 Il doit avoir de la validation à votre partie de code pour qu’elle soit suffisante pour la correction.
 Voici quelques exemples de features qui seraient suffisantes pour la correction :
-•	En Angular
-o	Enregistrement et connexion
-o	Consommer les évènements de la partie
-o	Gestion de la boucle de jeu
-	 (Alterner entre le polling pour mettre à jour le match et jouer une carte de sa main)
-•	En Web API
-o	Les combats et la génération des évènements
-o	AccountController, 
-	Si vous faites corriger AccountController, le contrôleur doit également inclure l'initialisation du joueur
-•	MVC
-o	Les outils d’administration
-	(Si vous avez fait une page pour arrêter les parties en cours, voir l’utilisateur en attente d’une partie, etc.)
-o	Gestion des cartes de départ
+- En Angular
+    - Enregistrement et connexion
+    - Consommer les évènements de la partie
+    - Gestion de la boucle de jeu
+        - (Alterner entre le polling pour mettre à jour le match et jouer une carte de sa main)
+- En Web API
+    - Les combats et la génération des évènements
+    - AccountController, 
+    - Si vous faites corriger AccountController, le contrôleur doit également inclure l'initialisation du joueur
+        - MVC
+- Les outils d’administration
+    - (Si vous avez fait une page pour arrêter les parties en cours, voir l’utilisateur en attente d’une partie, etc.)
+- Gestion des cartes de départ
 
-Tests unitaires
-•	Tester uniquement le backend
-•	Tester uniquement le / les services utilisé par la feature
-	Utiliser une InMemoryDatabase pour réaliser les tests
-•	Les tests doivent couvrir 100% des méthodes utilisées dans les services
+### Tests unitaires
+- Tester uniquement le backend
+- Tester uniquement le / les services utilisé par la feature
+    - Utiliser une InMemoryDatabase pour réaliser les tests
+- Les tests doivent couvrir 100% des méthodes utilisées dans les services

web/docs/03-tps/01-tp1.md

@@ -2,6 +2,20 @@
 
 ## L'application
 
+## TODO:
+- Réduire la tâche
+- Utiliser SignalR dès le début
+- Exiger l'utilisation de Reactive Forms pour la création du compte (avoir plus de questions)
+- Exiger l'utilisation de Guards
+- Exiger que l'utilisateur reste connecté
+- Signal R doit utiliser Authorize
+- Pas de tests dans la première partie
+- Fournir un Stub partiel pour pouvoir avancer la connection du Match sur le client
+- Demander que le nombre de cartes de départ soit configurable
+- Demander que les decks soient modifiables
+- Fournir des stats de cartes par défaut (minimum 10)
+- Ajouter un diagramme de classes comme livrable
+
 ### Objectifs : 
 - Créer un application web à l’aide d’Angular, Web API et MVC pour faire un jeu de carte.
 - Le site Angular sera utilisé par des membres inscrits. 
@@ -26,7 +40,8 @@
 
 ### Utilisateur
 - Un nouvel utilisateur doit obtenir un paquet de carte de départ.
-Partie
+
+### Partie
 - Un utilisateur peut jouer contre un autre utilisateur présent.
 - Chaque utilisateur doit jouer une carte par tour.
 - Chaque carte en jeu doit attaquer une autre carte à chaque tour et ainsi enlever des points de points de défense à l’autre carte.

web/docs/03-tps/02-tp2.md

@@ -2,6 +2,9 @@
 
 ## L’application
 
+## TODO:
+- Ajouter un diagramme de classes comme livrable
+
 ### Objectifs : 
 Ajouter des fonctionnalités au jeu de cartes développé lors du Sprint 1.
 

web/docs/03-tps/03-tp3.md

@@ -2,6 +2,9 @@
 
 ## L’application
 
+## TODO:
+- Ajouter un diagramme de classes comme livrable
+
 ### Objectifs : 
 Ajouter des fonctionnalités au jeu de cartes développé lors des Sprints 1 et 2.