Nicolas
cd8ce42df7
Socle backend, entièrement testable en CI, pour le tutoriel guidé. Le moteur front (driver.js), l'instrumentation `data-tour-*` et le CRUD admin viendront ensuite. Schéma (`schema.prisma` + migration `20260906120000_tour_scenarios`) — les 4 modèles de #44, qui révisent le registre statique prévu par #42 : - `TourTarget` (`key` PK + `description`) : catalogue des cibles de surlignage valides, seedé, comme `TechStep`/`Unit`. - `TourScenario` (`key` stable, `name`, `enabled`) : un scénario rejouable. - `TourScenarioStep` (`order`, `route?`, `targetKey`, `title`, `content`) : `title`/`content` sont du **texte libre**, pas des clés i18n (#44 : contenu administrable → texte, comme le nom d'une recette). - `TourProgress` (`userProfileId` + `scenarioId`, PK composite) : présence d'une ligne = scénario vu (terminé *ou* passé). Seed (`reference-seed-data.ts`) : les 9 `TourTarget` correspondant aux `data-tour-*` à poser côté front, + les 2 scénarios de #42 (`general`, `techStepMetadata`) **créés seulement s'ils sont absents** (un admin en devient propriétaire ensuite). `techStepMetadata` reste court pour l'instant — #36 (popover qui se ferme en pleine sélection) est ouvert, v1 ne couvre que les gestes qui marchent déjà. API : - `GET /reference/tours` (public) → scénarios **activés** + étapes ordonnées, forme consommée directement par le futur `useTour()`. - `GET /profile/tours` → `{ completedTourKeys: string[] }`. - `POST /profile/tours/:tourKey/complete` → upsert idempotent ; corps vide = terminé, `{ skipped: true }` = passé. Émet `analytics.recordEvent` `tour.completed` / `tour.skipped` (le dashboard admin agrège déjà tout type d'`AnalyticsEvent` génériquement — analytics de #44 quasi gratuites). 404 `TOUR_NOT_FOUND` (nouveau code 4053) sur une clé inconnue/désactivée. `reset-db.ts` truncate les 4 nouvelles tables (reseedées juste après). Tests Mocha : `GET /reference/tours` (scénarios + étapes ordonnées, exclusion d'un scénario désactivé) ; `/profile/tours` GET+POST (upsert idempotent, `skipped`, 404 clé inconnue, 404 tour désactivé, isolation par profil). Pas de base Postgres locale → exécutés en CI. Refs #42, #44 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
57 lines
2.8 KiB
TypeScript
57 lines
2.8 KiB
TypeScript
import { env } from "../src/config/env.js";
|
|
import { prisma } from "../src/db/prisma.js";
|
|
import { syncRecipeSources } from "../src/db/recipe-source-sync.js";
|
|
import { seedReferenceData } from "../src/db/reference-seed-data.js";
|
|
|
|
/**
|
|
* Refuses to run outside a database that's obviously a test one — belt and
|
|
* braces alongside `config/env.ts` loading `.env.test` (not `.env`) under
|
|
* `NODE_ENV=test`: this already wiped a real local dev database once, when
|
|
* both env files shared one `DATABASE_URL`. `resetDatabase()` below
|
|
* TRUNCATEs almost the entire schema before every single test, so a
|
|
* misconfigured/missing `.env.test` must fail loudly here rather than
|
|
* silently truncate whatever `DATABASE_URL` happens to be set.
|
|
*/
|
|
function assertRunningAgainstTestDatabase() {
|
|
if (env.NODE_ENV !== "test") {
|
|
throw new Error(
|
|
`resetDatabase() TRUNCATEs almost the whole schema — refusing to run outside NODE_ENV=test (currently "${env.NODE_ENV}").`,
|
|
);
|
|
}
|
|
// "test" covers a local `.env.test` (`batchcooking_test`); "ci" covers
|
|
// CI's own service database (`batchcooking_ci`, set directly via the
|
|
// workflow's `env:`, not a `.env.test` file — see ci.yml). Neither
|
|
// matches the real dev database's name (`batchcooking`), which is the
|
|
// one case this must actually catch.
|
|
if (!env.DATABASE_URL?.includes("test") && !env.DATABASE_URL?.includes("ci")) {
|
|
throw new Error(
|
|
`resetDatabase() refuses to run against a DATABASE_URL that doesn't look like a test database (got "${env.DATABASE_URL}", expected it to contain "test" or "ci") — see .env.test.example.`,
|
|
);
|
|
}
|
|
}
|
|
|
|
// Single TRUNCATE ... CASCADE covers FK ordering and resets identity
|
|
// sequences — used between tests/scenarios to start from a clean slate.
|
|
// Re-seeds the Diet/Category/Allergy/Unit reference data right after
|
|
// truncating it, so every test starts from the same realistic reference
|
|
// data the real app seeds (`prisma/seed.ts`) rather than empty tables —
|
|
// tests exercising dietId/allergyIds/unitId need real rows to reference.
|
|
// `syncRecipeSources` runs last, for the same reason: `sources` should
|
|
// reflect whatever adapters this test run happens to have registered
|
|
// (usually none — see recipe-source-registry.ts).
|
|
export async function resetDatabase() {
|
|
assertRunningAgainstTestDatabase();
|
|
await prisma.$executeRawUnsafe(`
|
|
TRUNCATE TABLE
|
|
"user_profile_allergy", "user_preference", "allergy", "category",
|
|
"planning_item", "planning",
|
|
"recipe_ingredient", "step_tech_step", "step", "tech_step",
|
|
"recipe", "ingredients", "sources", "unit",
|
|
"user_profiles", "diet", "house",
|
|
"tour_progress", "tour_scenario_step", "tour_scenario", "tour_target",
|
|
"admin_users", "analytics_events", "worker_heartbeats", "backfill_state"
|
|
RESTART IDENTITY CASCADE;
|
|
`);
|
|
await seedReferenceData(prisma);
|
|
await syncRecipeSources(prisma);
|
|
}
|