La reserva pública no ofrecía horarios en producción. La ventana laboral se
construía con `new Date(y, m, d, hh, mm)`, que resuelve el reloj de pared en la
tz del proceso. El Dockerfile no fijaba TZ y node:22-slim arranca en UTC,
mientras que la máquina de desarrollo está en America/Mexico_City: por eso solo
fallaba desplegado. Un negocio de 09:00-20:00 se publicaba como 09:00-20:00 UTC
(03:00-14:00 de México), y como el generador descarta lo anterior a ahora+30min,
a partir de la 1 PM la lista quedaba vacía.
Toda la API de scheduling.ts lleva ahora `tz` explícita y resuelve el reloj de
pared con wallToUtcDate/bizDateISO de time.ts, que ya existían para esto.
Arrastraba cinco defectos más en la misma ruta:
- getExistingBusy acotaba el día concatenando `${fecha}T00:00:00`. Como start_at
se guarda en UTC, una cita de las 19:00 de México vive en el día UTC siguiente
y quedaba fuera del rango: el guard anti doble-reserva no veía la tarde entera.
Ahora usa bizDayBoundsIsoFor.
- Un negocio recién sembrado nacía con working_hours y slug en NULL, o sea con
cero franjas agendables y /b/:slug en 404: el backfill vivía solo dentro de las
migraciones, que corren antes de que exista la fila. Los defaults se fijan en el
INSERT (server/lib/businessDefaults.ts) en los tres sitios que crean negocios, y
migrateV4ToV5 repara los ya rotos. El demo usa slug fijo `mi-negocio-demo`
porque es la URL ya publicada y el volumen se recrea en cada despliegue.
- El chip mostraba la hora formateada por el servidor y el resumen la del
navegador: dos horas distintas para el mismo slot. Ambas salen ahora del
instante resuelto en la tz del negocio.
- La separación mañana/tarde usaba /PM/i sobre un texto ya localizado, y es-MX
rinde "05:00 p.m." con puntos: nunca casaba, así que el grupo "Tarde"
desaparecía y toda la tarde se agrupaba bajo "Mañana".
- MonthCalendar comparaba canPrev contra el día 1 del mes visible en vez de
contra minDate, de modo que la flecha de mes anterior nunca se podía pulsar.
Las guardas de migración comparaban la versión como texto ("10" >= "2" es false),
lo que habría reejecutado migrateV1ToV2 y su DROP TABLE users al llegar a dos
dígitos; ahora comparan números.
Verificación: scheduling.test.ts fija TZ=UTC y usa negocios en America/Mexico_City
para que la tz del proceso y la del negocio nunca coincidan; el Dockerfile fija
ENV TZ=UTC por lo mismo. 43 unitarias + 33 e2e + 12 booking + 17 admin en verde
con el servidor en UTC y base recién sembrada; typecheck limpio. booking-e2e.mjs
busca el próximo día abierto en vez de asumir "mañana", que lo hacía fallar cada
viernes y sábado por calendario.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
76 lines
3.9 KiB
JavaScript
76 lines
3.9 KiB
JavaScript
// server/scripts/booking-e2e.mjs — requiere el server dev corriendo (npm run dev)
|
|
const BASE = "http://localhost:5173/api";
|
|
let pass = 0, fail = 0;
|
|
async function req(method, path, body, token) {
|
|
const headers = { "Content-Type": "application/json" };
|
|
if (token) headers.authorization = `Bearer ${token}`;
|
|
const res = await fetch(`${BASE}${path}`, { method, headers, body: body ? JSON.stringify(body) : undefined });
|
|
const text = await res.text();
|
|
let json; try { json = JSON.parse(text); } catch { json = text; }
|
|
return { status: res.status, json };
|
|
}
|
|
function check(name, cond, extra = "") {
|
|
if (cond) { pass++; console.log(` \u2713 ${name}`); }
|
|
else { fail++; console.log(` \u2717 ${name} ${extra}`); }
|
|
}
|
|
|
|
const { json: login } = await req("POST", "/auth/login", { email: "[email protected]", password: "demo1234" });
|
|
const t = login.token;
|
|
check("login owner", !!t);
|
|
|
|
// 1) Slug del negocio
|
|
const { json: settings } = await req("GET", "/settings", null, t);
|
|
const slug = settings.settings?.slug;
|
|
check("tiene slug", !!slug, String(slug));
|
|
|
|
// 2) Datos públicos + servicios
|
|
const { json: pub } = await req("GET", `/public/${slug}`);
|
|
check("public business", !!pub.business && Array.isArray(pub.services) && pub.services.length > 0);
|
|
const svc = pub.services[0];
|
|
|
|
// 3) Slots disponibles.
|
|
// Se busca el próximo día ABIERTO en vez de asumir "mañana": el negocio demo cierra
|
|
// sábado y domingo, así que fijar mañana hacía que la suite fallara cada viernes y
|
|
// sábado por calendario, no por un defecto del producto.
|
|
let date = null;
|
|
let slotsRes = null;
|
|
for (let i = 1; i <= 8; i++) {
|
|
const d = new Date(Date.now() + i * 86400000).toISOString().slice(0, 10);
|
|
const r = await req("GET", `/public/${slug}/slots?service_id=${svc.id}&date=${d}`);
|
|
if (i === 1) check("slots devuelve lista", Array.isArray(r.json.slots));
|
|
if (Array.isArray(r.json.slots) && r.json.slots.length > 0) { date = d; slotsRes = r.json; break; }
|
|
}
|
|
check("hay slots en algún día abierto de la próxima semana", !!slotsRes, date ? `fecha ${date}` : "ningún día con slots");
|
|
if (!slotsRes) { console.error("Sin slots en 8 días: revisa working_hours del negocio demo."); process.exit(1); }
|
|
|
|
// 4) Reservar (auto-asignación, sin employee_id)
|
|
const slot = slotsRes.slots[0];
|
|
const { status: bookStatus, json: booked } = await req("POST", `/public/${slug}/book`, {
|
|
service_id: svc.id,
|
|
start_at: slot.iso,
|
|
client: { name: "Cliente Prueba Auto", phone: "+525500000001" },
|
|
});
|
|
check("reserva creada (auto-assign)", bookStatus === 201 && !!booked.appointment?.employee_id, `status=${bookStatus}`);
|
|
check("response trae reasons", Array.isArray(booked.appointment?.reasons) && booked.appointment.reasons.length > 0);
|
|
check("response trae no_show_count", typeof booked.no_show_count === "number", `got ${typeof booked.no_show_count}`);
|
|
check("response trae risk_flag", typeof booked.risk_flag === "boolean", `got ${typeof booked.risk_flag}`);
|
|
check("cliente nuevo → sin riesgo", booked.no_show_count === 0 && booked.risk_flag === false, `ns=${booked.no_show_count} risk=${booked.risk_flag}`);
|
|
|
|
// 5) Mismo slot otra vez → 409 (doble reserva del mismo especialista)
|
|
const { status: conflict } = await req("POST", `/public/${slug}/book`, {
|
|
service_id: svc.id,
|
|
employee_id: booked.appointment.employee_id,
|
|
start_at: slot.iso,
|
|
client: { name: "Cliente Conflictivo", phone: "+525500000002" },
|
|
});
|
|
check("doble reserva → 409", conflict === 409, `status=${conflict}`);
|
|
|
|
// 6) Activar auto_assign_specialist y verificar que la respuesta pública lo expone
|
|
await req("PATCH", "/settings", { auto_assign_specialist: 1 }, t);
|
|
const { json: pub2 } = await req("GET", `/public/${slug}`);
|
|
check("auto_assign_specialist expuesto en público", pub2.business?.auto_assign_specialist === 1);
|
|
await req("PATCH", "/settings", { auto_assign_specialist: 0 }, t); // cleanup
|
|
|
|
console.log(`\n${pass}/${pass + fail} passed${fail ? `, ${fail} FAILED` : ""}`);
|
|
process.exit(fail ? 1 : 0);
|