Nicolas
deec91c5a3
Le conteneur de prod ne peuplait jamais la table Source : seed-runtime.ts (l'entrée seed de l'image Docker, exécutée après `prisma migrate deploy`) n'appelait que seedReferenceData(), jamais registerAllRecipeSources()/ syncRecipeSources() — contrairement à prisma/seed.ts (dev). server.ts enregistre bien les adaptateurs dans son propre registre en mémoire, mais c'est un processus distinct de celui qui lance seed-runtime.js dans la chaîne CMD du Dockerfile ; sans ce sync, GET /reference/sources renvoyait toujours [], et HouseholdSettingsPage masquait silencieusement toute la section sources (sources.length === 0 → return null). C'est ce que l'utilisateur a remarqué : impossible de paramétrer les sources visibles du foyer en prod. Vérifié en local : Source/HouseSource vidées, seed-runtime.js compilé relancé exactement comme le ferait le conteneur (migrate deploy déjà appliqué, puis ce script) → les deux sources (TheMealDB, JSON-LD) sont bien resynchronisées. Ajoute aussi la couverture Cypress du parcours "sources" qui manquait : - onboarding.feature : nouveau scénario où le catalogue de sources n'est pas vide — l'étape /onboarding/sources s'affiche et se soumet, au lieu du seul scénario existant qui la voyait toujours skippée (catalogue vide). - household-settings.feature : nouveaux scénarios pour la section sources de /parametres/foyer — affichage + sauvegarde (autosave incluse) quand des sources existent, et disparition complète de la section quand le catalogue est vide. - Nouvelles steps partagées (reference-data.steps.ts pour le catalogue, household-mutations.steps.ts pour la sélection par foyer). Non exécutés localement : Chromium/Electron headless plante au lancement du process GPU dans cet environnement (limitation documentée du README, reproductible sur main, sans lien avec ce changement) — vérifiés par relecture attentive contre le code source réel (libellés de traduction, routes, formes de requête/réponse) et en suivant le même gabarit que les scénarios existants déjà verts en CI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
85 lines
2.9 KiB
TypeScript
85 lines
2.9 KiB
TypeScript
import { Given, Then } from "@badeball/cypress-cucumber-preprocessor";
|
|
|
|
// Shared across household-settings.feature (dedicated create/join scenarios)
|
|
// and onboarding.feature (household step of the wizard) — both need to mock
|
|
// the create/join mutations and their up-to-date `GET /house/current`
|
|
// follow-up the same way.
|
|
|
|
const houseWithTwoMembers = {
|
|
id: 1,
|
|
name: "Chez Alice",
|
|
adminId: 1,
|
|
inviteCode: "ABCD2345",
|
|
members: [
|
|
{ id: 1, firstName: "Alice", lastName: "Martin" },
|
|
{ id: 2, firstName: "Bob", lastName: "Dupont" },
|
|
],
|
|
};
|
|
|
|
// The page reloads `GET /house/current` right after each mutation below
|
|
// succeeds — these intercepts need to answer differently before/after that
|
|
// follow-up GET, hence a shared mutable flag rather than a single static
|
|
// `cy.intercept` (a later static one would just win for every request,
|
|
// including the initial page load).
|
|
|
|
Given("creating a household will succeed", () => {
|
|
const createdHouse = {
|
|
id: 1,
|
|
name: "Chez Alice",
|
|
adminId: 1,
|
|
inviteCode: "ABCD2345",
|
|
members: [{ id: 1, firstName: "Alice", lastName: "Martin" }],
|
|
};
|
|
let created = false;
|
|
cy.intercept("GET", "**/house/current", (req) => {
|
|
req.reply({ statusCode: 200, body: created ? createdHouse : null });
|
|
});
|
|
cy.intercept("POST", "**/house", (req) => {
|
|
created = true;
|
|
req.reply({ statusCode: 201, body: createdHouse });
|
|
}).as("createHouse");
|
|
});
|
|
|
|
Given("joining a household will succeed", () => {
|
|
let joined = false;
|
|
cy.intercept("GET", "**/house/current", (req) => {
|
|
req.reply({ statusCode: 200, body: joined ? houseWithTwoMembers : null });
|
|
});
|
|
cy.intercept("POST", "**/house/join", (req) => {
|
|
joined = true;
|
|
req.reply({ statusCode: 200, body: houseWithTwoMembers });
|
|
}).as("joinHouse");
|
|
});
|
|
|
|
Then("the household creation request should have been made with name {string}", (name: string) => {
|
|
cy.wait("@createHouse").its("request.body").should("deep.equal", { name });
|
|
});
|
|
|
|
Then(
|
|
"the household join request should have been made with invite code {string}",
|
|
(code: string) => {
|
|
cy.wait("@joinHouse").its("request.body").should("deep.equal", { inviteCode: code });
|
|
},
|
|
);
|
|
|
|
// Shared between onboarding.feature's sources step and household-settings.feature's
|
|
// sources section — both read/write the same `/house/current/sources` endpoint.
|
|
|
|
Given("the household's enabled sources are empty", () => {
|
|
cy.intercept("GET", "**/house/current/sources", { statusCode: 200, body: [] });
|
|
});
|
|
|
|
Given("saving the source selection will succeed", () => {
|
|
cy.intercept("PATCH", "**/house/current/sources", (req) => {
|
|
req.reply({ statusCode: 200, body: req.body.sourceIds });
|
|
}).as("updateSources");
|
|
});
|
|
|
|
Then(
|
|
"the source selection update request should have been made with source id {int}",
|
|
(id: number) => {
|
|
cy.wait("@updateSources")
|
|
.its("request.body")
|
|
.should("deep.equal", { sourceIds: [id] });
|
|
},
|
|
);
|