Una de las primeras cosas que integré en mi flujo de desarrollo con IA fue la escritura de tests.
Los modelos son especialmente buenos en este terreno. Si les das contexto suficiente sobre una base de código, pueden generar suites de pruebas completas más rápido de lo que tardas en escribir un solo archivo de specs a mano.
Eso no significa dejar de revisar. Significa que el trabajo cambia de lugar: menos tiempo picando casos repetitivos y más tiempo decidiendo qué comportamiento importa, qué límites conviene cubrir y qué pruebas merecen quedarse.
El problema del exceso de pruebas
Hay una queja recurrente cuando se usa IA para testing: "tiende a probar demasiado". Demasiadas aserciones, demasiados casos límite, escenarios que quizá nunca habrías escrito manualmente.
Antes de la IA, esa preocupación tenía mucho peso. Cada test escrito era un test que alguien tenía que mantener. Si una suite crecía sin criterio, el coste acababa apareciendo en forma de lentitud, fragilidad y ruido.
Pero si la IA escribe los tests y también ayuda a mantenerlos, mientras tu papel pasa a ser supervisar, aprobar y orientar, un poco de exceso deja de ser tan grave. La economía de la calidad cambia.
El criterio sigue siendo necesario. No se trata de aceptar cualquier prueba generada. Se trata de reconocer que el coste marginal de explorar más casos ha bajado muchísimo, y eso abre espacio para cubrir comportamientos que antes se quedaban fuera por pura falta de tiempo.
Si usas Claude Code, crea una Testing Skill
La forma práctica de escalar esto no es pedir tests desde cero en cada conversación. Es convertir tus criterios en una Testing Skill compartida.
Esa skill debería empezar por tus patrones reales, no por una plantilla genérica. Deja que Claude revise primero tus tests actuales para entender el estilo del proyecto: cómo nombras los casos, qué helpers usas, cómo organizas fixtures, qué nivel de detalle tienen las aserciones y qué tipo de pruebas considera normal la aplicación.
Después define las reglas importantes:
- Estrategia de fixtures. Cuándo usar datos existentes y cuándo crear registros nuevos para el caso concreto.
- Límites para stubs. Qué se puede simular y qué no. APIs externas, llamadas lentas o servicios de terceros pueden tener sentido; esconder consultas o lógica de dominio suele ser más peligroso.
- Reglas de tiempo. Cómo se manejan fechas y horas para evitar tests frágiles o dependientes del día en que se ejecutan.
- Guardarraíles de comportamiento. Probar lo que el usuario o el sistema observan, no detalles internos. Nada de tests sobre métodos privados solo porque existen.
La clave es que todos trabajen con el mismo contexto. Si cada persona del equipo improvisa su propio criterio, la suite acaba reflejando preferencias individuales. Si todos usan la misma Testing Skill, la IA puede moverse deprisa sin romper la coherencia del proyecto.
Las pruebas E2E se han vuelto accesibles
El cambio más interesante aparece en las pruebas end-to-end.
Durante años, escribir y mantener E2E tests ha sido caro. Había que preparar datos, automatizar navegación, pelear con selectores, esperar estados de la interfaz y depurar fallos que a veces no tenían nada que ver con el producto.
Con la integración de navegador de Claude Code, muchos de esos casos empiezan con una especificación en lenguaje natural:
Inicia sesión como employee@test.com, crea 3 elementos de categorías
distintas, asígnalos a oficinas diferentes y genera un informe de
exportación CSV con esos elementos.
Eso ya describe el comportamiento completo. La IA puede traducirlo a pasos de navegador, inspeccionar la interfaz, ajustar selectores, ejecutar el flujo y dejar una prueba que el equipo pueda revisar.
Lo que antes era una tarea pesada de automatización se convierte en una conversación concreta sobre el recorrido que importa. Sigue haciendo falta criterio para estabilizar la prueba, elegir buenos datos y evitar acoplarla a detalles visuales frágiles, pero la barrera de entrada baja mucho.
La oportunidad inmediata
Mejorar cobertura y simplificar mantenimiento es una de las oportunidades más claras de la IA en equipos de producto.
Tiene poco riesgo, porque las pruebas no cambian el comportamiento de producción. Tiene mucha visibilidad, porque una suite más completa detecta regresiones antes. Y genera valor rápido, porque casi cualquier proyecto vivo tiene zonas importantes sin suficiente cobertura.
La condición es no tratarlo como una colección de prompts sueltos. Hace falta contexto compartido: cómo se prueba en este proyecto, qué se considera una buena prueba, qué no se debe acoplar y qué convenciones tiene que respetar la IA.
Ahí es donde una Testing Skill bien escrita marca la diferencia. La IA puede producir tests a gran velocidad, pero la consistencia es lo que permite que esa velocidad escale sin convertir la suite en ruido.
