Testing inteligente con playwright - Por qué las pruebas unitarias ya no bastan cuando la IA escribe el código

Durante años nos hemos reconfortado con una falsa sensación de seguridad: la pirámide de testing (con el unitario en la base) y la métrica dorada de cobertura cuanto más alta mejor. Y se lo endiñamos a los agentes para sentirnos más tranquilos.

Pero últimamente se ha dinamitado ese consenso. Y me duele reconocerlo porque fui profe de testing y practicante (no muy ferviente, la verdad) de TDD.

Entonces ¿ya no hacemos testing?. Sí, sí, pero la forma ya no es la misma, cobra mucha más fuerza el testing de comportamiento, llámalo integración, llámalo e2e, de comportamiento o como quieras.

Y de todas las herramientas que hay para implementarlo, cuando se trata de probar apps que escupen html o json, parece que Playwright se ha adueñado de la escena ;-)

El mismo autor a ambos lados

¿Dónde está el problema con el unit test? Pues que el testing unitario (y sobre todo el TDD) estaban pensados para obligar a los programadores humanos a pensar más de una vez (con la oportunidad de detectar alguna flaqueza en el entendimiento) sobre el problema y a crear un código más mantenible (por aquello de las dependencias).

Cuando delegas la escritura del código a un modelo de lenguaje, y le pides al mismo que haga la prueba unitaria, pues la prueba unitaria se queda en una tautología: el test repite el código, con otras palabras.

Un test escrito por el mismo agente que escribió el código se limita a parafrasearlo.

Esto se puede evitar (hasta cierto punto), escribiendo el test con otro agente (incluso un modelo distinto), pero, además de un coste de contexto doble, lo que hará sera intentar entregar algo que funcione. Y no un test que valide el comportamiento esperado.

El coverage cuenta líneas ejecutadas. Los herramientas de mutación ponen al test contra las cuerdas. Y los tests de propiedades lo llevan a explorar limites de rangos… Pero no aportan gran cosa si el comportamiento no es el esperado.

No los tires a la basura. Los unitarios siguen en su sitio para un comprobar un cálculo o una función compleja. Ahí son útiles y baratos. Y evitan errores inadvertidos por un toque humano.

Pero la certificación de que hace lo que se espera tiene que salir de otro sitio.

Integración, porque la verdad está ahí fuera

Un E2E abre el navegador, rellena y mira la página. Si el botón no hace nada, falla. No hay mock ni prompt que valga. Es la simulación más real de lo que le ocurrira´a tus usuarios.

Tampoco hace falta una suite enorme. ConEmpieza por el camino feliz y el fallo gordo. Eso es lo que da o quita dinero. Continúa con el caso vacío, o el de permisos, y pide que mida tiempos. Esa inverisón renta más que el 100% unitario.

Otra cosa es que esta prueba sea barata, no lo es. De hecho, es más complejo, lento y costoso que un test unitario. Pero cuando detecta algo… es mucho más valiosa.

Playwright en el centro de la escena

Para toda tarea hay su herramienta. Hasta hace poco mis tests e2e los hacía mano con Cypress. Me parecía una gozada. Facil de programar, bonito y agradble de usar y depurar. Lo usé durante años y gané dinerito con é. Muchas gracias.

Selenium nunca me gustó. Sé que en el mundo corporate tenía su nicho… pero para mi está muerto y enterrado. Por pesado, por feo y por lento.

El original Puppeteer me encantó, para empezar por el nombre, y uso mucho su envotorio de pruebas de rendimiento y SEO Lighthouse (otro nombre que me mola). Pero ya. Para expresar selectores, aserciones y agrupar pruebas… nada como el wrapper que le hicieron los de Microsoft: enter Playwright.

Tien un poco de lo mejor de los anteriores. Por debajo es Puppeter con su control del navegador, por encima tiene todo lo necesario para hacer testing de comportamiento como haría Selenium. Y, con la facilidad de uso de Cypress. Pero, la magia de que el agente lo escriba y lo repare con menos inventos es que estaba en el lugar adecuado en el momento oportuno.

Como sabes, los LLM se entrenan con código público… y quizá privado. A Playwright le ocurrión lo mismo que React (más bien Next), es lo que más han leído, lo que mejor conocen, y lo que prefieren usar.

Así que tenemos ganador, una herramienta buena (todas lo son), bonita (cada vez importa menos) y barata (más conocimiento, menos slop, menos tokens).

Conclusión

El impacto de la inteligencia artificial en el desarrollo de software está en redefinir qué parte de nuestro trabajo aporta verdadero valor. Pero también del trabajo de los agentes. Mover cómputo (es decir tokens, es decir money) de un proceso a otro es algo natural en nuestra profesión.

Me pongo pedante: cuando escribir código deja de ser el cuello de botella, medir la calidad por la cantidad de pruebas unitarias o la cobertura de líneas es un anacronismo peligroso. La labor del desarrollador senior pasa de la artesanía sintáctica (sí, yo la hecho de menos) a la arquitectura de verificación (del comportamiento): diseñar los límites, los criterios de aceptación y poner los arneses que los agentes no puedan eludir.

Apostar por Playwright es fiarse del framework mejor integrado en el entrenamiento de los LLMs. Esa es la baza para programar con agentes sin perder el control de la calidad.

Estoy incorporando todas estas ideas en AIDDbot, un arnés de skills para agentes. Es open source, así que puedes ver cómo controlo a mis agentes y, mejor aún, ayudarme a incrementar la calidad de su desarrollo.

Una cosa más: si te interesa este tema y quieres aprender a usar Playwright en tu proceso de desarrollo con IA, puedes echar un vistazo al curso que voy a publicar próximamente.