Différences

Ci-dessous, les différences entre deux révisions de la page.

--- d5:a02 [2025/09/18 08:49] – créée dthevenot
+++ d5:a02 [2025/09/18 09:44] (Version actuelle) – [A02 : Les tests (unitaires et d'intégration)] dthevenot
@@ Ligne 1: / Ligne 1: @@
-===== A02 : Les tests unitaires =====
+====== Ressources ======
+  * https://zestedesavoir.com/tutoriels/274/les-tests-unitaires-en-java/
+  * https://codegym.cc/fr/groups/posts/fr.191.tests-unitaires-en-java-avec-junit
+  * https://www.machinet.net/tutorial-fr/java-unit-test-guide
+===== A02 : Les tests (unitaires et d'intégration) =====
+__Durée estimée__ : 4 heures
 ==== Objectif pédagogique ====
   * Comprendre la différence entre tests unitaires, d’intégration, fonctionnels et de performance.
@@ Ligne 14: / Ligne 19: @@
 Vous allez développer et tester progressivement ce projet.
   - récupérer le projet sur gitea
-<bootnote warning>Dans Netbeans, cloner le dépôt, créer sa branche -votre prénom- et **ne travailler que sur votre branche**, commiter avec commentaire précis sur votre branche uniquement</bootnote>
+<bootnote warning>Dans Netbeans :
+  - cloner le dépôt (https://delphine.thevenot@gitea.lyc-lecastel.fr/delphine.thevenot/2026TestsBibliotheque.git),
+  - créer votre branche -votre prénom- et **ne travailler que sur votre branche**
+  - commiter avec un commentaire précis sur votre branche uniquement
+</bootnote>
   - Étudier les classes fournies (Livre, Utilisateur).
   - exécuter les tests existants / être capable de les expliquer
   - Compléter les méthodes manquantes (ex. calcul du prix TTC d’un livre, ajout d’un livre dans la liste d’un utilisateur).
 =====  =====
+====== Les tests unitaires ======
   - Écrire des **tests unitaires** avec JUnit pour :
     - vérifier les méthodes de la classe Utilisateur
     - Vérifier le calcul du prix TTC.
     - Vérifier que l’ajout d’un livre à un utilisateur fonctionne.
-    - Ajouter au moins 2 tests supplémentaires par classe pour couvrir des cas limites (ex. : emprunter plus de 3 livres, prix négatif, etc.).
+    - Ajouter au moins 2 tests supplémentaires par classe(y compris la classe Emprunt) pour couvrir des cas limites (ex. : emprunter plus de 3 livres, prix négatif, etc.).
   - Exécuter les tests et corriger les bugs si nécessaire.
-<bootnote critical>Travail validé par la présentation d'un test à la classe</bootnote>
+<bootnote critical>Travail validé par la présentation d'un test à la classe le **vendredi 26/09**</bootnote>
 =====  =====
-**Les tests d'intégration :**
+====== Les tests d'intégration ======
 Vous aller vérifier que plusieurs composants du système fonctionnent correctement ensemble.
@@ Ligne 36: / Ligne 48: @@
     * le livre n’est pas déjà emprunté
     * l’utilisateur a moins de 3 emprunts
-  - Vérifier que l’état du livre et la liste des emprunts de l’utilisateur sont correctement mis à jour.
+  - Vérifier que l’état du livre(emprunté ou pas) et la liste des emprunts de l’utilisateur sont correctement mis à jour.
-=====  =====
-==== Etape1 : les tests unitaires  ====
-=== Qu'est-ce qu'un test unitaire ? ===
-Un test unitaire est un test automatisé écrit en même temps, voire même avant le programme lui
-même. Il ne valide qu'une portion très réduite du code source (par exemple certaines méthodes
-d'une seule classe). Il permet de vérifier le bon fonctionnement d'une partie spécifique d'une
-application. (Une unité = un module, une classe, une méthode …).
-=== Pourquoi effectuer des tests unitaires ? ===
-Les tests unitaires vont permettre d'apporter une réponse à 3 problèmes récurrents :
-  * Problème de coordination entre développeurs
-Une application est souvent réalisée par plusieurs développeurs qui travaillent en parallèle sur une
-base de code commune. il est fréquent que des modifications effectuées par un programmeur
-entrainent à son insu des dysfonctionnements sur d'autres parties du code que la sienne. Les autres
-programmeurs constatent alors avec surprise que leurs parties du projet ne fonctionnent plus, sans
-qu'ils aient modifié quoi que ce soit au code. En pratique, ces "effets de bord" néfastes constituent
-souvent les erreurs les plus frustrantes et les plus difficiles à résoudre dans le cycle de
-développement logiciel.
-  * Problème de maintenance
-En entreprise, la fin du codage initial ne signifie pas la fin du projet : il y aura forcément des bugs à
-corriger, des améliorations demandées par le client, des modifications, etc. Il n'est pas rare que la
-durée de vie couvre plusieurs années au-delà de son développement initial. Les tests permettront de
-vérifier que le programme fonctionne toujours après une modification.
-  * Besoin de rassurer le client
-Aucun client n'acceptera de payer un logiciel sans savoir s'il fonctionne correctement.
-=== Le principe des tests unitaires ===
-Le principe des tests unitaires est le suivant : au lieu d'effectuer des tests de façon intuitive en
-exécutant le programme selon divers paramètres ou d'écrire isolément des morceaux de code de
-test non réutilisables, on ajoute au projet une série de tests automatisés ciblant chacun une partie
-précise du projet.
-Si toutes les parties essentielles du code source sont validées par des tests unitaires, alors le projet
-global a de bonnes chances de fonctionner correctement.
-Les tests unitaires sont montrables au client souhaitant faire des vérifications.
-De plus, les tests unitaires étant toujours à disposition, ils permettront de valider facilement et
-rapidement toute modification apportée ultérieurement au code source, ce qui évite l'introduction
-de nouveaux bugs dans le projet.