Aller au contenu

Story AB-001 : Environnement de développement + Infrastructure de test

Module : absence-management Slice : VS-AB-001 from architecture Brand context : [BOTH] Papillon HR Suite + ALTARYS ENTERPRISE HR Suite Priority : 1 Depends on : Aucune Can develop concurrently with : Aucune (doit être livrée en premier) Merge order : Avant AB-002 Estimated complexity : S PRD User Stories : N/A - Technical Story

Objectif

Mettre en place l'environnement de développement et l'infrastructure de test pour le module Absence Management afin que toutes les stories suivantes disposent d'un Docker Compose fonctionnel, d'une configuration TestContainers et de fixtures de test. C'est un prérequis pour toutes les autres stories AB — aucune logique métier ne peut être développée ou testée sans cette fondation.

Périmètre Backend

Entités & Records

Aucune entité métier dans ce slice. Il s'agit uniquement d'infrastructure de test.

Classes de support de test à créer :

  • AbsenceTestContainersConfiguration.java — Configuration TestContainers partagée pour le module absence. Démarre les containers PostgreSQL + Redis. Configure les propriétés Spring DataSource pour le contexte de test.
  • AbsenceTestFixtures.java — Méthodes factory pour les données d'exemple :
  • createSampleLeaveRequest() — retourne un LeaveRequest valide avec des valeurs par défaut réalistes
  • createSampleEmployeeProfile() — retourne un LeaveEmployeeProfile valide avec des soldes à zéro
  • createSampleLedgerEntry() — retourne une entrée d'accumulation LeaveBalanceLedger valide
  • TestLeaveRequestFixture.java — Fixture avec pattern Builder et API fluide pour LeaveRequest, permettant de surcharger les valeurs par défaut (tenant, employé, dates, statut, type de congé)

Couche Repository

N/A — Aucun repository dans ce slice. Les repositories sont créés dans AB-002.

Couche Service

N/A — Aucun service dans ce slice.

Endpoints API

N/A — Aucun endpoint dans ce slice.

Règles de validation

  • Les fixtures de test doivent produire des entités qui passent toutes les règles de validation définies dans AB-002
  • BigDecimal pour tous les champs montant/jour dans les fixtures (jamais float/double)
  • Tous les champs date utilisent LocalDate, tous les champs timestamp utilisent Instant
  • tenant_id doit être non-null dans toutes les fixtures générées

Considérations multi-tenant

  • Les fixtures de test doivent accepter tenantId en paramètre pour supporter les 4 profils DB (shared, schema-per-tenant, DB-per-tenant, BYO-DB)
  • AbsenceTestContainersConfiguration utilise le profil shared par défaut pour simplifier
  • Les méthodes de fixture doivent générer des valeurs tenant_id uniques par test pour éviter la contamination inter-tests
  • Docker Compose doit supporter les surcharges spécifiques au profil via des variables d'environnement

Périmètre Frontend

N/A — Story d'infrastructure backend.

Pages & Routes

N/A

Composants

N/A

États UI (TOUS REQUIS)

N/A — Backend uniquement.

Comportement responsive

N/A

Interactions

N/A

Critères d'acceptation

AC-001: Docker Compose starts all dependencies
Given the developer runs docker-compose up -d
When the services start
Then PostgreSQL and Redis are accessible on their default ports

AC-002: TestContainers integration works
Given a test class extends AbsenceTestContainersConfiguration
When the test runs
Then a PostgreSQL container is automatically started and connected

AC-003: Test fixtures generate valid data
Given the AbsenceTestFixtures class is available
When a test calls createSampleLeaveRequest()
Then a valid LeaveRequest is created with all required fields populated and BigDecimal amounts

Règles OHADA & réglementaires

N/A — Story d'infrastructure sans logique métier.

Standards & conventions

  • docs/standards/java-spring-guidelines.md — §Testing, §TestContainers setup, §Records & sealed types
  • docs/standards/database-guidelines.md — §Multi-tenant repository pattern, §Connection pooling
  • docs/standards/multi-datasource-patterns.md — §TestContainers multi-datasource configuration

Exigences de test

Tests unitaires

  • AbsenceTestFixtures.createSampleLeaveRequest() retourne une entité avec tous les champs requis non-null
  • AbsenceTestFixtures.createSampleEmployeeProfile() retourne une entité avec annual_balance_ouvrables = BigDecimal.ZERO
  • Le builder TestLeaveRequestFixture surcharge correctement les valeurs par défaut

Tests d'intégration

  • Les containers PostgreSQL + Redis de Docker Compose démarrent et acceptent les connexions
  • AbsenceTestContainersConfiguration injecte une DataSource fonctionnelle dans le contexte de test
  • Les entités de fixture peuvent être persistées et récupérées (validé après l'existence des migrations AB-002)

Ce que la QA validera

  • N/A — Pas de fonctionnalité visible par l'utilisateur. Le développeur auto-valide que l'infrastructure de test fonctionne.

Hors périmètre

  • Logique métier, services ou endpoints API
  • Migrations Flyway et schéma de base de données (AB-002)
  • Configuration frontend de quelque nature que ce soit
  • Configuration de test Keycloak ou authentification (utilise l'infrastructure de test existante de la plateforme)
  • Logique de cache Redis (le container Redis est démarré pour usage futur)

Définition de Done

  • [ ] Tous les endpoints backend implémentés et retournant les réponses correctes — N/A (pas d'endpoints)
  • [ ] Toutes les pages frontend s'affichent correctement à 360px, 768px, 1024px — N/A (backend uniquement)
  • [ ] Les 5 états UI implémentés (loading, empty, error, offline, success) — N/A
  • [ ] Le micro-copy français correspond exactement à la spec de design — N/A
  • [ ] Tous les critères d'acceptation passent manuellement
  • [ ] Tests unitaires écrits et passants
  • [ ] Tests d'intégration écrits et passants
  • [ ] Isolation multi-tenant vérifiée — Les fixtures de test supportent la paramétrisation du tenant_id
  • [ ] L'écriture + synchronisation offline fonctionne (Papillon) / N/A (Enterprise) — N/A (backend uniquement)
  • [ ] Pas de TypeScript any — N/A
  • [ ] Pas de Java raw types — tous les generics explicites
  • [ ] Les réponses API suivent le format d'enveloppe standard — N/A (pas d'endpoints)
  • [ ] Entrées de piste d'audit pour chaque mutation de données — N/A (pas de mutation de données)