# Story: Tests for Actualité Feature (DTO, Enricher, CreationService, Tag CRUD)

## 1. Contexte (Context)

This story covers the automated test coverage for the Actualité news page template feature: DTO validation, enricher behavior (including previous/next edge cases), page creation business logic, the new repository method, the `Tag` entity/service, and functional tests for the two new API surfaces (Actualité page creation, Tag CRUD). While tests can be drafted/stubbed early alongside their corresponding implementation stories, this story naturally closes last, since it validates the combined output of the "Tag entity + admin CRUD", "Actualité DTO/Model + CreationService", and "PageRepository::findPublishedByTemplate() + previous/next enricher" stories. A manual QA checklist item for the full inline-editor add/remove/reorder/save/reload cycle is also included, since that flow is not practically covered by automated tests.

## 2. Le besoin (User Story)

```
En tant qu'équipe de développement de ce projet
Je souhaite disposer d'une suite de tests automatisés couvrant la validation, l'enrichissement, la création de page et les opérations CRUD sur les tags pour la fonctionnalité Actualité
Afin de garantir la non-régression de cette fonctionnalité lors de futures évolutions
```

## 3. Liens utiles (Useful Links)

- **Spec source**: `spec-driven-development/2026-07-07-actualite-news-page-template.md`, task group "Testing"
- **Depends on implementations from**:
  - Story "Tag entity + admin CRUD" (`stories/actualite-tag-entity-admin-crud.md`)
  - Story "Actualité DTO/Model + CreationService + TemplateMatcher registration" (`stories/actualite-dto-model-creation-service.md`)
  - Story "PageRepository::findPublishedByTemplate() + previous/next enricher logic" (`stories/actualite-previous-next-enricher.md`)
- **Test conventions**: `docker-compose exec php vendor/bin/phpunit` (CLAUDE.md "Testing" section); existing test patterns under `tests/Page/{Template}/` for About/List, `tests/Repository/PageRepositoryTest.php` for existing repository test conventions

## 4. Critères d'acceptation (Acceptance Criteria)

### Scénario 1: Tests de validation du DTO de contenu Actualité
```gherkin
Scénario: ActualitePageContentDtoTest couvre les cas valides et invalides
  Étant donné `tests/Page/Actualite/Dto/ActualitePageContentDtoTest.php`
  Quand la suite est exécutée
  Alors un payload complet valide (mainImage + N blocs mixtes) passe la validation sans violation
  Et un payload avec des champs requis manquants échoue avec les violations attendues
  Et un payload avec un `block.type` invalide échoue
  Et des valeurs valides/invalides de `mobileImagePosition` sur les blocs texte+image sont testées explicitement
  Et un test confirme explicitement l'absence de tout champ CTA sur le DTO
```

### Scénario 2: Tests de l'enricher Actualité
```gherkin
Scénario: ActualitePageEnricherTest couvre tous les cas de figure
  Étant donné `tests/Page/Actualite/Service/ActualitePageEnricherTest.php`
  Quand la suite est exécutée
  Alors elle couvre : une page avec 0 bloc, une page avec des blocs de types mixtes, 0/1/plusieurs tags, le cas premier article (pas de précédent), le cas dernier article (pas de suivant), et le cas article unique (ni précédent ni suivant)
```

### Scénario 3: Tests du service de création de page Actualité
```gherkin
Scénario: ActualitePageCreationServiceTest couvre la logique métier de création
  Étant donné `tests/Page/Actualite/Service/ActualitePageCreationServiceTest.php`
  Quand la suite est exécutée
  Alors elle vérifie que la création avec `blocks: []` réussit
  Et qu'une collision de slug est rejetée
  Et que le `template` est forcé à `'actualite'` indépendamment de la valeur fournie dans le DTO
  Et que des `tagIds` valides sont bien assignés à la page créée
  Et que des `tagIds` inconnus sont rejetés avant toute persistance
```

### Scénario 4: Tests du repository — findPublishedByTemplate
```gherkin
Scénario: PageRepositoryTest couvre la nouvelle méthode findPublishedByTemplate
  Étant donné `tests/Repository/PageRepositoryTest.php` (étendu ou créé)
  Quand la suite est exécutée
  Alors elle vérifie l'exactitude du tri par `publishedAt`
  Et elle vérifie que seules les pages avec `isPublished = true` sont retournées
```

### Scénario 5: Tests de l'entité Tag et du service de gestion
```gherkin
Scénario: TagTest et TagManagementServiceTest couvrent les règles métier des tags
  Étant donné `tests/Entity/TagTest.php` et/ou `tests/Service/Tag/TagManagementServiceTest.php`
  Quand la suite est exécutée
  Alors elle vérifie l'application de la contrainte d'unicité sur name/slug
  Et la génération automatique du slug à partir du name
  Et la politique de blocage de suppression lorsque le tag est utilisé par une page publiée
```

### Scénario 6: Test fonctionnel de création de page Actualité via API
```gherkin
Scénario: Le endpoint de création Actualité retourne le format JSON attendu
  Étant donné un test fonctionnel appelant `POST /api/admin/pages/actualite/create`
  Quand la requête est envoyée avec un payload valide incluant `tagIds`
  Alors la réponse est une `JsonResponse` au format `{success: true, data: {...}}`
  Et une requête avec un payload invalide retourne `{success: false, error: "..."}` avec un code HTTP approprié
  Et l'assignation des `tagIds` est vérifiée en base après création
```

### Scénario 7: Tests fonctionnels du CRUD Tag via API
```gherkin
Scénario: TagApiController est couvert par des tests fonctionnels CRUD complets
  Étant donné des tests fonctionnels ciblant `GET/POST/PUT/DELETE /api/admin/tags`
  Quand chaque endpoint est appelé avec des payloads valides et invalides
  Alors chaque réponse respecte le format `{success, data|error}`
  Et les erreurs de validation (ex. nom manquant, nom déjà utilisé) retournent un code HTTP 400 avec un message clair
```

### Scénario 8: Checklist de QA manuelle pour le cycle complet de l'éditeur
```gherkin
Scénario: Le cycle complet ajout/suppression/réordonnancement/sauvegarde/rechargement est vérifié manuellement
  Étant donné que les tests automatisés ne couvrent pas l'intégralité du flux UI de l'éditeur inline
  Quand la checklist de QA manuelle est exécutée (non automatisée, à cocher avant mise en production)
  Alors elle confirme, en contexte FR et EN : le cycle complet ajout/suppression/réordonnancement/sauvegarde/rechargement fonctionne
  Et que les tableaux de blocs restent indépendants par locale
  Et que la persistance de `mobileImagePosition` par bloc est correcte
  Et que la persistance de l'assignation des tags est correcte
```