Hace unos meses un compañero me pasó una suite de tests “generada con IA” para
que le diera el visto bueno. Todo en verde, muy bonito. Tardé diez minutos en
ver que la mitad no probaba nada: clicks que no comprobaban el resultado,
selectores pegados al CSS que se rompían en cuanto alguien tocaba el HTML, y un
par de expect que pasaban siempre, hicieras lo que hicieras.
Esa es la trampa de pedirle al modelo “escríbeme todos los tests”. Te los escribe. Y se ven bien. El problema es que un test que no falla cuando algo se rompe de verdad es peor que no tener test, porque te deja tranquilo sin motivo.
Y aun así, uso IA con Playwright casi todos los días y me ahorra un montón de tiempo. La gracia está en cómo repartes el trabajo.
Yo decido qué se prueba, la IA me ayuda a escribirlo
La parte que no delego nunca es la de decidir qué importa: qué flujos son críticos, qué pasa si esto falla un viernes a las seis, qué significa que algo esté “bien”. Eso depende de conocer el producto y el negocio, y el modelo no los conoce.
Lo que sí suelto, una vez que tengo claro el caso, es la parte mecánica. Ahí es donde gano horas de verdad:
- Paso un caso de prueba manual (los pasos y lo que debería ocurrir) y me devuelve un primer borrador en Playwright que luego reviso y endurezco.
- Le pido que saque los selectores repetidos a page objects. Es trabajo aburrido y repetitivo, justo lo que no me apetece hacer a mano.
- Cuando un test se pone flaky, le pego el error y la traza. Casi siempre el problema es una espera mal puesta.
Los selectores son donde se nota si sabes lo que haces
Por defecto la IA tira de selectores CSS o de texto exacto, y esos son los
primeros en romperse. Siempre la reconduzco hacia los locators que recomienda
Playwright: getByRole, getByLabel, getByText, y getByTestId cuando no hay
un rol claro. CSS o XPath, solo si no queda otra.
Con poner una línea en el prompt (“usa getByRole y getByTestId, nada de
selectores CSS frágiles”) cambia por completo lo que te entrega. Lo mismo con las
esperas: prohíbe waitForTimeout y pídele aserciones que esperan solas, tipo
expect(locator).toBeVisible(). Te quitas de encima la mitad de los tests
intermitentes de un plumazo.
Lo que miro antes de hacer merge
No me importa si el test lo escribió la IA o yo. Antes de que entre, le paso la misma lista:
¿Prueba algo que un usuario real hace, o un detalle interno que da igual? ¿El assert fallaría si el feature se rompe de verdad? ¿Aguanta un cambio de maquetado? ¿Es determinista, sin sleeps ni dependencias de orden? Y la más importante: ¿lo entiendo lo suficiente como para arreglarlo dentro de seis meses cuando reviente y yo ni me acuerde de este código?
Si no pasa esa lista, fuera. Da igual quién lo haya escrito.
En resumen
La IA no me hace el QA. Me quita de encima lo tedioso para que yo dedique el tiempo a lo que de verdad cuesta: pensar en el riesgo, decidir qué vale la pena probar y discutirlo con el equipo. Escribir tests más rápido está bien. Escribir los tests correctos es lo que importa, y esa parte sigue siendo mía.