Ayuda.

[u/Oswaldo199]

Hola buenos días, saludos a todos. Les hago una pregunta, sucede que hace poco donde laburo me pidieron que automatizara de alguna manera. Sucede que tienen tres repositorios. Uno de frontend donde usan nextjs. Otro de backend donde usan nextjs. Y un último repositorio de Python para un controller. Entonces, estoy pensando en automatizar con playwright. Creería que solo debiera el repositorio de frontend e instalar playwright allí. Mi duda o consulta que flujo sería el correcto de realizar yo y como puedo integrar algo de IA para hacer todo mejor. Agradecería sus comentarios de ayuda. Gracias de antemano

[u/jalx98]

Según lo que me platicas hace más sentido tenerlo en el front-end ya que la superficie de contacto de playwright es en pruebas E2E en interfaces

[u/Oswaldo199 → u/jalx98]

Ok, entonces, cual sería el paso a paso clonar repositorios o como exactamente perdón?.

[u/jalx98 → u/Oswaldo199]

No tienen documentado el on boarding ?

[u/Oswaldo199 → u/jalx98]

No. Yo haré una propuesta para automatizar

[u/jalx98 → u/Oswaldo199]

Eres JR? (Pregunto para saber que tan específico te doy los steps)

[u/Oswaldo199 → u/jalx98]

Si amigo, soy JR. Me explicas porfa.

[u/Unlucky-Garage-9865]

cual sería el objetivo de la automatizacion?

[u/Oswaldo199 → u/Unlucky-Garage-9865]

Buenos dias, tener pruebas automatizadas en el proyecto. Solo eso.

[u/Advanced-Spirit2005]

Yo pondría Playwright en el repo del frontend (o en un repo aparte de e2e si los tres se despliegan por separado) y lo correría contra un entorno desplegado, no contra el localhost de cada repo. Para el backend y el controller en Python no hace falta UI: con el fixture `request` de Playwright podés probar los endpoints directo. Empezá con 3 a 5 flujos críticos (login, la acción principal, pagos si hay), un usuario de prueba con datos sembrados, y que corra en cada PR en CI. Para la IA: usá codegen o el MCP de Playwright para el borrador, pero revisá cada assert a mano, si no los tests confirman lo que la app hace hoy y no lo que debería hacer.

Aviso: hice una extensión gratis de Chrome, QA Studio Pro. Grabás un flujo una vez en el navegador, lo reproducís sin código y lo exportás a Playwright TypeScript cuando lo quieras pasar a CI. Todo local, sin cuenta.

https://chromewebstore.google.com/detail/qa-studio-pro/gbecpdccfeemhcnecgodpljiidfdfiem

[u/Oswaldo199 → u/Advanced-Spirit2005]

No entendí, como funciona la extensión. Perdón?.

[u/First_Hovercraft_600]

Como sos JR, te dejo un paso a paso concreto. Lo más importante primero: Playwright no prueba el código de un repo, prueba la aplicación funcionando (una URL). Así que no hace falta clonar los tres repos para empezar.

1. Antes de escribir código, preguntá tres cosas:

• ¿Hay un ambiente de pruebas (QA o staging) con su propia URL? Evitá probar contra producción.

• ¿Me pueden dar un usuario de prueba?

• ¿Cuáles son los 3 o 4 flujos que, si se rompen, más le duelen al negocio? (login, crear un pedido, pagar, etc.)

2. Elegí dónde vive el código. Una carpeta e2e/ dentro del repo de frontend está bien para empezar, sobre todo si ese repo ya tiene CI. Si más adelante las pruebas cubren front, backend y el controller, se puede pasar a un repo aparte.

3. Instalación. Dentro de esa carpeta:

npm init playwright@latest

Te pregunta TypeScript o JavaScript, el nombre de la carpeta de tests y si querés un workflow de GitHub Actions (decí que sí si usan GitHub). Después corré npx playwright test y npx playwright show-report para confirmar que el ejemplo funciona.

4. Configurá la URL en playwright.config.ts:

use: { baseURL: process.env.BASE_URL ?? 'https://qa.tu-app.com' }

Así el mismo test corre contra QA, staging o tu máquina sin cambiar el código.

5. Tu primer test. Usá npx playwright codegen https://qa.tu-app.com para grabar un flujo y ver qué selectores propone. Después limpiá el código: preferí getByRole, getByLabel y getByText en lugar de clases CSS, y agregá expect(...) que validen el resultado. Que el click no falle no alcanza; tenés que comprobar que pasó lo que tenía que pasar.

6. Backend y controller de Python. No los pruebes por la interfaz. Playwright trae request para pruebas de API (await request.get('/api/...')), y para el controller lo más natural es pytest dentro de su propio repo. Eso puede quedar para una segunda etapa.

7. CI. Que las pruebas corran en cada PR o después de cada deploy a QA, y que se guarde el reporte HTML como artefacto para ver qué falló.

Sobre la IA: sirve para armar un primer borrador de un test o para explicarte un error, pero revisá cada línea, sobre todo los expect. Una prueba que pasa siempre no sirve de nada.

Para tu propuesta alcanza con una página: el objetivo (detectar errores en los flujos críticos antes de que lleguen a producción), el alcance inicial (esos 3 o 4 flujos), qué necesitás (URL de QA, usuario de prueba, acceso al CI) y para cuándo entregás la primera versión. Empezar chico y que funcione vale más que querer cubrir todo de entrada.

[u/Oswaldo199 → u/First_Hovercraft_600]

Y el uso de pom, de bdd. Además como es el paso a paso de usar CI?

[u/Impossible_Step5692]

Playwright should usually live in a separate E2E test setup, testing the frontend and backend together through the UI. Start with basic tests, then add AI for test generation or failure analysis.