# mylibrary — back-end Java (méthode BDD)

Back-end du projet **2026-DEV-BUT3**. Reproduit, en Java pur, le cœur métier
de l'API consommée par le front React `my-library/`.

## Méthode

Conformément au cours `maintenanceApplicativeCours1.pdf` (Behavior-Driven
Development), pour chaque comportement on :

1. Écrit le scénario attendu (en Gherkin / `.feature` ou en `@DisplayName` JUnit)
2. Écrit le test qui le vérifie
3. Implémente le code qui fait passer le test

## Structure (calquée sur le module `customer` fourni par le prof)

```
src/main/java/fr/iut_fbleau/but3/dev62/mylibrary/
├─ customer/        Module fourni par l'enseignant (intact)
│  ├─ CustomerInfo.java   record d'entrée
│  ├─ CustomerDTO.java    DTO de sortie
│  ├─ entity/             Customer (objet métier, règles fidélité)
│  ├─ exception/          Exceptions métier
│  ├─ converter/          Mapping Info <-> entity <-> DTO
│  ├─ validator/          Règles de validation
│  ├─ repository/         Stockage en mémoire (List)
│  └─ usecase/            Cas d'usage (orchestration)
└─ book/             Module développé en miroir (notre travail)
   └─ … (mêmes sous-paquets, même découpage)

src/test/java/.../mylibrary/
├─ customer/         Tests JUnit fournis par l'enseignant
├─ book/             Tests JUnit que nous avons écrits
└─ features/
   ├─ RunCucumberTest.java         (du prof, intact)
   ├─ client/CustomerSteps.java    (du prof, intact)
   ├─ book/BookSteps.java          (notre travail)
   └─ resources/features/
      ├─ client.feature            (du prof, intact)
      └─ book.feature              (notre travail)
```

## Dépendances

Strictement les mêmes que dans le template du prof :

- JUnit 5 (jupiter-api, params, engine + platform-suite, platform-engine, platform-launcher)
- Mockito (core, junit-jupiter)
- Cucumber (cucumber-java, cucumber-junit-platform-engine)
- Lombok

## Build & test

Pré-requis : **JDK 21** + **Maven 3.9+**

```bash
mvn -f mylibrary test
```

Cette commande exécute :

- les tests unitaires JUnit (entity, validator, converter, repository, usecase, exceptions)
- les scénarios Cucumber (`client.feature` + `book.feature`) via `RunCucumberTest`

## Périmètre couvert

Conformément à la consigne (« reproduire le strict nécessaire pour démontrer
la maîtrise »), l'API se limite aux deux domaines présents dans le swagger
qui structurent l'app React :

- **Catalogue** (`book`) : enregistrer, consulter par ISBN, lister tous les livres,
  refuser ISBN dupliqué, refuser un livre invalide, gérer le stock.
- **Comptes clients** (`customer`) : enregistrer, consulter par téléphone, mettre
  à jour, supprimer, ajouter / retirer des points de fidélité (module fourni).

L'exposition HTTP réelle utilisée par les développeurs front est l'API du prof
(`mylibrary-0.0.1-SNAPSHOT.jar`) ; ce module sert à démontrer la maîtrise
de la **conception métier en BDD/TDD**.