87 lines
3.5 KiB
Markdown
87 lines
3.5 KiB
Markdown
# E2E visual baseline — instrucciones de uso
|
|
|
|
Este README explica cómo verificar que un `token` y una `room` habilitan la videollamada con el flujo E2E del proyecto.
|
|
|
|
Requisitos
|
|
- Node.js (>=16)
|
|
- Chrome/Chromium instalado en el host donde corras la prueba
|
|
- Opcional: browserless si no quieres ejecutar Chrome local
|
|
|
|
Archivos relevantes
|
|
- `packages/broadcast-panel/e2e/generate_visual_baseline.js` — script E2E que crea una sesión en el token server, se conecta a Chrome remoto/browserless, navega al estudio y publica token vía postMessage.
|
|
- `packages/broadcast-panel/e2e/start-chrome-remote.sh` — script para arrancar Chrome/Chromium en modo remote-debugging.
|
|
|
|
Flujo de verificación paso a paso
|
|
|
|
1) Levantar token server (opcional si ya tienes uno)
|
|
|
|
Si no tienes un token server, puedes usar la ruta Next.js incluida: `/app/api/session/route.ts`.
|
|
- Asegúrate de tener `LIVEKIT_API_KEY` y `LIVEKIT_API_SECRET` en el entorno (o usa un mock server local).
|
|
|
|
2) Arrancar Chrome con remote debugging
|
|
|
|
Opción segura (localhost):
|
|
|
|
```bash
|
|
cd packages/broadcast-panel/e2e
|
|
chmod +x start-chrome-remote.sh
|
|
./start-chrome-remote.sh
|
|
```
|
|
|
|
Opción con exposición pública (NO RECOMENDADA):
|
|
```bash
|
|
REMOTE_DEBUG_PUBLIC=1 REMOTE_DEBUG_PORT=9222 ./start-chrome-remote.sh
|
|
```
|
|
|
|
3) Comprobar endpoint CDP
|
|
|
|
```bash
|
|
curl -sS http://localhost:9222/json/version
|
|
curl -sS http://localhost:9222/json/list
|
|
```
|
|
|
|
Busca `webSocketDebuggerUrl` en la salida.
|
|
|
|
4) Ejecutar el script E2E
|
|
|
|
```bash
|
|
# ejemplo apuntando al chrome local y al token server local (Next.js en 3000 o 3001)
|
|
REMOTE_DEBUG_ADDRESS=127.0.0.1 REMOTE_DEBUG_PORT=9222 TOKEN_SERVER="http://localhost:3001" ROOM="e2e-room-1" BROADCAST_URL="http://url_dominio_publico/room/:idroom" node packages/broadcast-panel/e2e/generate_visual_baseline.js
|
|
```
|
|
|
|
El script escribirá logs a `e2e/out/generate_visual_baseline.log` y guardará capturas en `e2e/out/visual_<timestamp>/studio.png`.
|
|
|
|
5) Validar en el frontend que el token es recibido
|
|
|
|
El script hace `window.postMessage({ type: 'LIVEKIT_TOKEN', token })`. En el frontend (estudio) debes tener un listener similar a:
|
|
|
|
```js
|
|
window.addEventListener('message', (ev) => {
|
|
if (ev.origin !== window.location.origin) return;
|
|
if (ev.data && ev.data.type === 'LIVEKIT_TOKEN') {
|
|
const token = ev.data.token;
|
|
// conectar a LiveKit con token: room.connect(serverUrl, token) o usando components-react
|
|
}
|
|
});
|
|
```
|
|
|
|
6) Debug rápido
|
|
|
|
- Si `createSession` falla: revisa `TOKEN_SERVER` y mira `curl -v TOKEN_SERVER/api/session`.
|
|
- Si no se resuelve CDP: valida `curl http://localhost:9222/json/version`.
|
|
- Si el frontend no conecta: abre la consola del navegador (o inspecciona la ejecución en Puppeteer con page.on('console') logs en `e2e/out/generate_visual_baseline.log`).
|
|
|
|
7) Qué revisar si la videollamada no se inicia
|
|
|
|
- El token tiene que ser válido (LIVEKIT_API_KEY/SECRET correctos y server LiveKit accesible desde el frontend).
|
|
- `studioUrl` debe corresponder al dominio público donde está el frontend. `BROADCAST_URL` o `studioUrl` devuelto por el token server debe ser exactamente la URL que abrirás (por ejemplo: `https://miapp.example/room/abc123`).
|
|
- El frontend debe usar el token para conectar al room (Room.connect o LiveKit components).
|
|
|
|
|
|
Si quieres, puedo:
|
|
- Añadir una ruta de verificación GET `/api/session/:id` que devuelva la sesión guardada (facilita recuperar token tras POST).
|
|
- Añadir un mock server `tools/mock-token-server.js` para pruebas locales sin credenciales.
|
|
|
|
Dime si quieres que cree el mock-server o adapte la API a un flujo GET/POST adicional.
|
|
|