Tests

Le TDD est obligatoire pour toute fonctionnalité : on aligne le besoin, on écrit les tests qui échouent (rouge), on implémente jusqu'au vert, et tous les tests passent avant de marquer la tâche terminée.

Deux tiers de tests

Tier	Fichiers	Ce qu'ils font
Intégration (primaire)	tests/**/*.spec.ts	Instancient le vrai service et frappent une SQLite :memory:.
E2E	tests/e2e/	Démarrent l'app NestJS complète avec une SQLite in-memory réelle.

Les tests d'intégration sont le tier principal : ils sont rapides et exercent la logique métier réelle contre une base réelle.

Lancer les tests

pnpm run test         # tests d'intégration
pnpm run test:watch   # mode watch
pnpm run test:cov     # avec couverture
pnpm run test:e2e     # tests e2e

Tous tournent avec NODE_ENV=test.

Organisation

Les fichiers de test reflètent l'arborescence source :

Source	Test
app/auth/auth.service.ts	tests/app/auth/auth.service.spec.ts
web/guards/require-workspace.guard.ts	tests/web/guards/require-workspace.guard.spec.ts

Setup de la base

Chaque fichier de test importe '../../db-setup' en tête. Ce module exécute, dans un beforeAll global, un sequelize.sync({ force: true }) et seede les groupes par défaut.

Le schéma est remis à zéro une fois par fichier

tests/db-setup.ts utilise beforeAll, pas beforeEach : le schéma est recréé une fois par fichier de test, pas entre chaque test. Les valeurs sous contrainte UNIQUE (noms de groupes, emails, noms de workspaces) doivent donc être distinctes entre tous les tests d'un même fichier.

Ordre de troncature et contraintes FK

Les contraintes de clés étrangères sont appliquées. Dans les beforeEach, on tronque les tables qu'on modifie en ordre enfant-d'abord, et on seede les lignes parentes (users, workspaces, groups) avant les enfants (memberships, notifications, invitations).

Factories

Les factories vivent dans tests/factories/<entity>.factory.ts et exportent build<Entity>(overrides?): <Entity> retournant une entité de domaine avec des valeurs par défaut basées sur faker.

import { buildUser } from '../../factories/user.factory';

const user = buildUser({ email: 'closer@acme.test' });

En savoir plus

Pour les patterns détaillés — seeding avec prérequis FK, stub des dépendances de service, accès typé aux modèles dans les specs — voir la compétence ikloze-testing du dépôt.