====== D5-A02 : Les tests unitaires ======
__Durée estimée__ : 4 heures
<bootnote critical>Travail validé par la présentation de sa validation(au moins 1 test) à la classe le **vendredi 26/09** à 11h</bootnote>
===== Ressources =====
  * https://junit.org/junit4/javadoc/latest/org/junit/Assert.html
  * 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

===== Rappel =====
Un test automatisé est un programme qui se découpe en trois phases dites AAA pour Arrange, Act, Assert :
  - **Arrange** : La mise en place de l’environnement : création et initialisation des objets nécessaires à l’exécution du test.
  - **Act** : Le test proprement dit.
  - **Assert** : La vérification des résultats obtenus par le test.
Le sous-système (l’ensemble des objets) éprouvé par le test est parfois appelé SUT (System Under Test).

===== Objectif pédagogique =====
  * Comprendre la différence entre tests unitaires, d’intégration, fonctionnels et de performance.
  * Savoir écrire et exécuter des tests avec un framework (**en Java avec JUnit** / en PHP avec PHPUnit).
  * Prendre conscience de l’importance de l’automatisation et des bonnes pratiques de validation.
=====  =====
===== Contexte : Bibliothèque numérique =====
Vous travaillez pour une startup qui développe une application de gestion de bibliothèque.
L’application doit permettre :
  * La gestion d’un catalogue de livres.
  * L’ajout et la suppression d’utilisateurs.
  * La gestion des emprunts (règle : un utilisateur ne peut pas emprunter plus de 3 livres).

L’application a un fonctionnement actuel minimal et nous allons nous concentrer sur la gestion des livres.

**Objectif** : améliorer la qualité et la sécurité des données via les tests unitaires, d’intégration et fonctionnels.
=====  =====
Vous allez développer et tester progressivement ce projet.
  * récupérer le projet sur gitea 
<bootnote warning>Dans Netbeans :
  - cloner la branche **developpement** du 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 et pusher sur votre branche personnelle uniquement
</bootnote>

<badge>Travail à faire1</badge>
  - Étudier la classe Livre et la classe de tests unitaires correspondante (LivreTest)
  - Identifier les 3 parties AAA de chaque test
  - Que vérifient les tests ?
  - Ajouter un message clair en cas d'erreur sur chaque test
  - Qu’est-ce qui n’est pas testé ?
  - Quels risques pour la sécurité si ces vérifications manquent ?
  
=====  =====
===== Evolution du contexte : nouveaux tests unitaires =====
Vous allez mettre en place de nouveaux tests pour assurer :
  * la validation des champs (titre, auteur, ISBN),
  * la robustesse face aux entrées malveillantes (XSS, caractères interdits),
  * l’intégrité globale des données 
 
<badge>Travail à faire2</badge>

Chaque étudiant va implémenter une nouvelle règle de validation :
  - (//Emile//)-ISBN : doit avoir 13 chiffres (pas de lettres, pas de caractères spéciaux), exemple invalide : "1234ABCD567".
  - (//Salomé//)-Titre : ne doit pas contenir <script> (chevron) (risque XSS).
  - (//Medhi//)-Auteur : non vide, pas de caractères spéciaux suspects, de chiffres, espaces autorisés (nom prénom), - autorisé (noms composés)
  - (//Morgann//)-Longueur maximale du titre (ex. 200 caractères - l'objectif cybersécurité étant d'éviter surcharge et attaques par dépassement de mémoire (DoS)).
  - (//Steve//)-Le titre doit être non vide et contenir au moins 2 caractères alphabétiques (Objectif : éviter les titres vides, réduits à un seul caractère, ou remplis uniquement de chiffres/symboles)
 
**Consignes** : Pour chaque règle :
  - Compléter la méthode prévue dans la classe de contrôle LivreValide
  - Créer la méthode correspondante dans la classe LivreValideTest avec ses tests unitaire JUnit.


=====  =====