fix(admin-monitoring): remplace le filtre resourceType cassé par une vérification manuelle #32
1 changed files with 34 additions and 16 deletions
|
|
@ -53,21 +53,33 @@ describe("Admin monitoring", () => {
|
|||
});
|
||||
|
||||
// The page route `/admin/monitoring` and the API path `GET /admin/monitoring`
|
||||
// are identical — a plain `**/admin/monitoring` glob would also match the
|
||||
// are identical — a plain `**/admin/monitoring` glob also matches the
|
||||
// `cy.visit()` document request (and whether that's same-origin or not
|
||||
// depends on `VITE_API_URL`, which isn't set in CI). `resourceType: "fetch"`
|
||||
// pins the intercept to the `AdminApiClient` XHR only.
|
||||
const monitoringApi = {
|
||||
method: "GET",
|
||||
url: "**/admin/monitoring",
|
||||
resourceType: "fetch",
|
||||
} as const;
|
||||
// depends on `VITE_API_URL`, which isn't set in CI).
|
||||
//
|
||||
// This used to be disambiguated with a declarative `resourceType: "fetch"`
|
||||
// route matcher, but that stopped working (Cypress 13.17.0 on this
|
||||
// machine's Chrome 152): the *declarative* `resourceType` matcher no
|
||||
// longer catches this request at all — confirmed by logging every request
|
||||
// Cypress hands to a `{resourceType: "fetch"}` intercept, which only ever
|
||||
// saw `/admin/auth/me`, never `/admin/monitoring` — even though the very
|
||||
// same request's own `req.resourceType`, read *inside* a handler matched
|
||||
// by url/method alone, reliably reads back `"fetch"`. So the request *is*
|
||||
// correctly typed; only the pre-filtering by that type is broken. Reading
|
||||
// `req.resourceType` inside the handler and branching manually (as below)
|
||||
// isn't affected by that bug and reproduced correctly in every check.
|
||||
function interceptMonitoringApi(response: { statusCode: number; body: unknown }) {
|
||||
return cy.intercept("GET", "**/admin/monitoring", (req) => {
|
||||
if (req.resourceType === "document") {
|
||||
req.continue();
|
||||
return;
|
||||
}
|
||||
req.reply(response);
|
||||
});
|
||||
}
|
||||
|
||||
it("renders one card per service with its status and details", () => {
|
||||
cy.intercept(monitoringApi, {
|
||||
statusCode: 200,
|
||||
body: monitoringFixture(),
|
||||
}).as("getMonitoring");
|
||||
interceptMonitoringApi({ statusCode: 200, body: monitoringFixture() }).as("getMonitoring");
|
||||
cy.visit("/admin/monitoring");
|
||||
cy.wait("@getMonitoring");
|
||||
|
||||
|
|
@ -85,11 +97,17 @@ describe("Admin monitoring", () => {
|
|||
});
|
||||
|
||||
it("shows an error state when the request fails", () => {
|
||||
cy.intercept(monitoringApi, {
|
||||
statusCode: 500,
|
||||
body: { code: 5000, message: "x" },
|
||||
});
|
||||
// Aliased and waited on (unlike the other tests' plain intercepts) so
|
||||
// this genuinely proves the 500 came from the mock — without a live API
|
||||
// server, an unmatched request fails at the network level too, which
|
||||
// `MonitoringPage`'s `.catch()` can't tell apart from a real 500 (see
|
||||
// the comment above `interceptMonitoringApi`, this is exactly the class
|
||||
// of bug that let this test pass for the wrong reason before).
|
||||
interceptMonitoringApi({ statusCode: 500, body: { code: 5000, message: "x" } }).as(
|
||||
"getMonitoringError",
|
||||
);
|
||||
cy.visit("/admin/monitoring");
|
||||
cy.wait("@getMonitoringError");
|
||||
cy.contains("Impossible de charger").should("be.visible");
|
||||
});
|
||||
});
|
||||
|
|
|
|||
Loading…
Reference in a new issue