Cómo hago tests de mi web sin saber testear ni programar
Mi web tiene tests automáticos y yo no los he escrito. Los hace la IA y me avisan antes de que algo se rompa en producción.
Mi web tiene tests automáticos. Yo no he escrito ninguno.
Y sí, soy programador de formación, así que te veo venir. Pero te digo una cosa: escribir tests nunca ha sido lo mío. Es de esas tareas que todo el mundo sabe que hay que hacer, que nadie disfruta y que se posponen hasta el día en que algo revienta en producción y te enteras porque te escribe un alumno.
Eso pasó. Un cambio pequeño en el sistema de acceso a los cursos y durante unas horas hubo gente que no podía entrar. Nadie lo detectó. Ni yo, ni el despliegue, ni nada. Se detectó porque una persona me escribió un correo.
A partir de ahí monté los tests. O más bien, se los pedí a la máquina.
¿Para qué sirven los tests si no programo?
Un test es una comprobación automática que se ejecuta sola cada vez que tocas algo.
Nada más. No es una tecnología misteriosa, no requiere carrera. Es un archivo que dice "cuando un usuario con acceso entra en la lección, tiene que ver el vídeo". Y una máquina ejecuta esa frase cada vez que cambias una línea. Si deja de cumplirse, te avisa antes de publicar.
Traducido a lo que te importa si no programas: es un vigilante que prueba tu web por ti a las tres de la mañana, gratis, sin cansarse y sin saltarse pasos.
Y esa es exactamente la razón por la que le interesa a alguien que construye con IA. Cuando tú no escribes el código, tú tampoco lo revisas. La IA hace un cambio, tú miras que la pantalla se vea bien, y das por hecho que lo demás sigue funcionando. No siempre sigue funcionando.
Los tests son el contrapeso. Es lo que evita que una IA que arregla errores sola te arregle una cosa y te rompa otra sin que nadie se entere.
Cómo se lo pedí
Abrí Claude Code en el proyecto de la web y le dije esto, casi con estas palabras:
"Quiero tests automáticos de las cosas que si se rompen me hacen perder dinero o me traen un correo enfadado. No quiero cobertura completa. Quiero cubrir los cinco caminos críticos. Dime cuáles crees que son antes de escribir nada."
Y ahí está el truco entero, en la última frase. No le pedí tests. Le pedí que me dijera qué merecía la pena testear.
Me devolvió una lista. Registro de usuario. Login. Compra de un curso. Acceso a una lección de un curso comprado. Y el bloqueo de acceso a una lección no comprada, que es el reverso del anterior y el que más caro se paga si falla.
Le dije que sí a los cinco y que empezara. Escribió los tests, los ejecutó, dos fallaban de entrada y los arregló. En una tarde tenía funcionando algo que llevaba años sin hacer.
Qué escribe exactamente y qué veo yo
Lo que escribe son archivos de código. Los abrí, los leí por encima y son sorprendentemente legibles: "ir a la página de login, escribir este correo, escribir esta contraseña, pulsar el botón, comprobar que aparece el panel". Prácticamente inglés.
Lo que veo yo es una lista en la terminal. Cinco líneas en verde cuando todo va bien y una línea en rojo cuando algo se ha caído, con el detalle de qué esperaba y qué se encontró.
Y aquí viene lo importante, porque el valor no está en tener los tests. Está en cuándo se ejecutan.
Los tengo puestos en dos momentos. Uno, cada vez que le pido a la IA un cambio con cierta miga, le digo que ejecute los tests antes de darme el trabajo por terminado. Dos, en el propio despliegue: si los tests fallan, el cambio no llega a producción.
Ese segundo punto es el que cambia la vida. Antes publicaba y cruzaba los dedos. Ahora publico y si algo se ha roto, la web pública sigue como estaba.
Lo que se te va a atascar
Los tests que fallan por motivos tontos. Cambias un texto de un botón y el test que buscaba ese texto se cae. No hay ningún error real, pero se pone en rojo. La primera semana te desespera. Se resuelve pidiendo que los tests busquen elementos por su función y no por su texto exacto, y hay que decirlo explícitamente porque de serie no lo hace siempre.
El test que pasa siempre. Es el peor de todos, porque te da tranquilidad falsa. Me pasó con uno de pagos que en realidad no comprobaba nada. La forma de detectarlo es rompiendo la funcionalidad a propósito y viendo si el test se pone rojo. Si rompes algo y el test sigue verde, ese test no sirve. Lo hago ahora con cada test nuevo.
Querer testearlo todo. La tentación es decirle "hazme tests de toda la web". No lo hagas. Acabas con doscientos tests, la mitad frágiles, tardando cinco minutos en ejecutarse y con la sensación permanente de que hay cosas en rojo que no importan. Cinco tests que siempre están verdes valen más que doscientos que ignoras.
Los datos de prueba. Los tests necesitan usuarios y compras de mentira para trabajar. Si eso se mezcla con los datos de verdad, la lías. Le pedí a la IA que montara una base de datos aparte para los tests y que la limpiara al terminar. Es un paso extra y hay que pedirlo, porque si no te lo va a montar de la forma más rápida, que no es la más segura.
La red de seguridad completa
Los tests no van solos. Van con dos cosas más que hacen que construir con IA deje de dar miedo.
Los checkpoints para deshacer, que te dejan volver atrás cuando la IA se ha liado a base de bien. Los tests te dicen que algo se rompió. Los checkpoints te devuelven al momento anterior.
Y el hábito de no publicar en caliente. Los tests verdes no significan que todo esté bien, significan que las cinco cosas críticas siguen funcionando. Es una red, no una garantía.
Lo que ha cambiado en el día a día
Publico más. Suena contradictorio, porque a priori los tests son un paso más y un paso más frena.
Pero es al revés. Antes, cada cambio que tocaba la zona de pagos o de accesos me daba pereza porque sabía que tenía que ir a comprobarlo todo a mano. Y lo que da pereza se pospone. Ahora hago el cambio, ejecuto, veo cinco verdes y publico.
El ahorro no es de tiempo. Es de la sensación de estar caminando por un tejado.
Si estás empezando a construir cosas con IA y todavía no sabes muy bien qué le puedes pedir y qué no, échale un ojo a cómo funciona esto para gente que no programa. Los tests no son el primer paso, pero deberían ser de los primeros diez.
Porque el problema de construir con IA no es que se rompa. Es enterarte tarde.
Si quieres montar tu web con Claude Code de principio a fin, incluyendo esta parte de que no se te caiga, lo tienes todo aquí.
Sigue leyendo
He creado un comité de expertos con IA para decidir en mi negocio
Director de producto, marketing, finanzas y SEO. Todos con IA. Se sientan a discutir mis decisiones y a veces votan sin que yo esté delante.
Por qué no uso RAG ni bases de datos vectoriales en IA
Todo el mundo monta RAG por defecto. Te explico cuándo las bases de datos vectoriales no tienen sentido y qué uso en su lugar: contexto y subagentes.
Cómo creé un consejo directivo con IA que trabaja por mí
Monté un consejo directivo con IA: CEO, CFO, estratega y más. Me cuestionan cada decisión antes de tomarla. Así funciona y así lo creas tú.
Opus o Sonnet: qué modelo elegir en Claude Code según la tarea
El modelo caro no siempre gana. Cuándo compensa Opus, cuándo Sonnet y cómo repartirlos en Claude Code sin fundirte el plan a mitad de semana.