Aller au contenu principal

Tests backend

Statut​

Document de cadrage backend — v1.0 — relu le 2026-05-11.

État actuel​

Le dossier api/tests contient des tests feature par module :

  • Actor (dont XpSecurityTest, XpAutomaticTest) ;
  • Admin ;
  • Analytics ;
  • AssoSuite ;
  • Auth ;
  • Chat ;
  • Community ;
  • Mairie ;
  • Middleware ;
  • Monetization ;
  • PlayLoop ;
  • Publication ;
  • Rewards ;
  • Settings ;
  • Territory.

Le script Composer test exécute php artisan test après config:clear.

321 tests — 1 153 assertions (état au 2026-05-24).

Configuration de test — PostgreSQL local​

Les tests tournent sur PostgreSQL via le Docker Supabase local.

.env.testing :

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=dmv_test
DB_USERNAME=postgres
DB_PASSWORD=postgres
DB_SSLMODE=disable

phpunit.xml : les variables DB_* sont fixées avec force="true" pour écraser .env.

La base dmv_test est une base dédiée aux tests, séparée de la base de développement (postgres). Elle est créée une fois (CREATE DATABASE dmv_test) et maintenue par RefreshDatabase.

Compatibilité PostgreSQL dans les tests​

  • Les colonnes boolean doivent être testées avec true/false PHP (pas 1/0) dans assertDatabaseHas.
  • Les UUIDs de test doivent respecter le format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12).
  • PostgreSQL est strict : uuid = varchar sans cast est rejeté — les jointures doivent utiliser des colonnes de même type.

Objectifs des tests​

Les tests doivent protéger :

  • contrats API ;
  • règles d'autorisation ;
  • validation ;
  • services métier ;
  • jobs ;
  • modération ;
  • monétisation ;
  • scopes par application ;
  • régressions sur modules partagés.

Types de tests​

TypeUsage
Feature APIVérifier endpoints, statuts HTTP, payloads, droits.
UnitTester logique pure ou petits objets.
ServicesVérifier règles métier sans HTTP quand pertinent.
JobsVérifier exécution, retry et effets attendus.
MiddlewareVérifier headers, auth, source app.
PoliciesVérifier autorisations fines.

Conventions cible​

  • Un module important doit avoir ses tests Feature.
  • Une règle métier critique doit avoir un test dédié.
  • Les tests doivent couvrir succès et refus.
  • Les statuts 401, 403, 422 et 404 doivent être vérifiés.
  • Les payloads sensibles doivent être testés pour non-exposition.

Commande​

cd api
composer test

ou :

php artisan test

Points restants à clarifier​

  • Couverture minimale attendue par module.
  • Tests d'intégration Supabase/Stripe.
  • Tests de queues et jobs.
  • Tests futurs de l'AI Gateway.