Qué elimina realmente el vibe testing
Elimina el paso de traducción. Normalmente ya sabes qué comportamiento quieres y luego dedicas una hora a convertirlo en selectores, esperas y aserciones, y la mayor parte de eso tiene que ver con el framework, no con tu producto. Describir el comportamiento y dejar que un agente se encargue de la traducción conserva la parte que aporta significado y descarta la que no.
Lo segundo que elimina es el coste de mantenimiento. Un paso expresado como intención sobrevive a un rediseño que un selector fijo no sobrevive, porque la intención sigue siendo cierta cuando el botón cambia de sitio.
Dónde falla una comprobación descrita
Demasiado imprecisa para fallar
"Comprueba que el dashboard funciona" no puede fallar, porque no se afirmó nada concreto.
Nombra lo observable: qué número, qué fila, qué estado.
Comprobar la acción
"Haz clic en Guardar" es un paso, no una comprobación. Una ejecución puede llevarlo a cabo y no demostrar nada.
Di qué debería ser cierto después, y que sea algo que una recarga confirmaría.
Sujeto ambiguo
"El usuario ve sus pedidos" deja sin definir de qué usuario se trata, y ahí es exactamente donde viven los errores de permisos.
Di de quién son los pedidos, y comprueba que otra persona no puede verlos.
El hábito que separa las comprobaciones reales de las decorativas
Rompe a propósito lo que quieres comprobar y confirma que la comprobación se pone en rojo. Lleva un minuto y es la única prueba de que la comprobación está conectada a algo.
Aquí importa más que con las pruebas escritas a mano, porque una comprobación descrita deja más margen para una interpretación generosa. Una ejecución que termina sin llegar a ninguna aserción no es una prueba superada, y la única forma de descubrir que tienes una es intentar que falle.
Primeros pasos
La instalación añade la capacidad al agente de código, de modo que las comprobaciones se describen y se ejecutan en el mismo sitio donde se escribe el código.
Nada de esto requiere terminal. Crea un proyecto en el dashboard de TestSprite, describe la comprobación en lenguaje natural y apúntala a tu aplicación. Los desarrolladores de tu equipo pueden hacer lo mismo desde la línea de comandos si lo prefieren, que está en el repositorio del CLI.
Qué describir primero
El flujo que enseñarías en una demo. Si se rompe, te enteras en público, así que debería ser lo primero que cubras.
Cualquier cosa que implique dinero o permisos. El mayor coste cuando algo está mal, y los dos fallan en silencio.
Lo último que se rompió. Lo que te pilló una vez merece una comprobación permanente, y ya sabes exactamente cómo describirla.
Describir una comprobación que aguante
La diferencia entre una comprobación que te protege y otra que solo decora el pipeline está casi siempre en cómo se describió, y ese patrón se puede aprender.
Una buena descripción tiene tres partes: un estado inicial, una acción y algo observable al final que una recarga confirmaría. "Como usuario con la sesión iniciada y sin filtros guardados, crea un filtro llamado Recent, recarga y confirma que aparece en la barra lateral." Cada una de esas partes puede fallar, y el fallo te dice dónde.
Compáralo con "comprueba que los filtros funcionan". La misma intención, sin estado inicial, sin acción concreta, sin nada observable. Un agente al que le pidas cumplir eso hará algo razonable e informará de que todo fue bien, y tú no habrás aprendido nada. Los quince segundos de más que dedicas a la primera versión son toda la diferencia.
Y deja de decidir cuándo ejecutarlas
Descrita o escrita en código, una comprobación que espera a que la lance una persona es una comprobación que se salta en una semana ajetreada.
Conecta el repositorio desde el dashboard y las ejecuciones arrancan desde el despliegue que ya generas, o añade un paso a tu propio flujo de trabajo.
Qué hace TestSprite con una comprobación descrita
Tú dices qué debería ser cierto; TestSprite averigua cómo comprobarlo y lo ejecuta contra tu aplicación desplegada. El paso de traducción, la parte que nunca fue lo importante, desaparece.
Dos propiedades hacen que el resultado dure. Los pasos se guardan como intenciones y no como rutas a través del DOM, así que un rediseño que mueve un botón no rompe la comprobación. Y el resultado vuelve como una descripción de qué se intentó, qué pasó y en qué punto ambas cosas divergieron, que es lo que permite a un agente de código actuar sobre un fallo sin que antes lo interprete una persona.
El refinamiento también se queda en lenguaje natural. Si una comprobación es demasiado laxa, dilo en una frase en lugar de editar código, que es justo la razón por la que merece la pena tener comprobaciones descritas.
¿Es el vibe testing lo bastante fiable para un producto real?
Para cubrir el comportamiento de los flujos, sí, siempre que cada comprobación nombre algo concreto y hayas confirmado que puede fallar. Para aserciones de secuencia exacta o a nivel de componente, las pruebas escritas siguen siendo la mejor herramienta.
¿En qué se diferencia esto de grabar una secuencia de clics?
Una grabación captura un recorrido y se rompe cuando el recorrido cambia. Una comprobación descrita captura una intención y sobrevive al cambio, y ahí está la mayor parte de la diferencia en mantenimiento.
¿Y si el agente interpreta mi descripción de otra manera?
Lee una vez los pasos generados antes de fiarte de la comprobación. Los errores de interpretación se ven a simple vista ahí y son mucho más difíciles de detectar después, en un resultado que pasa.
¿Puedo refinar una comprobación sin reescribirla?
Sí. Ajústala en lenguaje natural, igual que la describiste al principio.
¿Esto sustituye a las pruebas unitarias?
No. Las pruebas unitarias son más rápidas y mejores con la lógica. Esto cubre la capa que ellas no ven: si el producto ya ensamblado se comporta correctamente.
Describe algo concreto y luego haz que falle una vez.
El vibe testing elimina la traducción de la intención al código de prueba, que es la parte que nunca fue lo importante. Nombra algo observable y concreto, confirma que la comprobación puede ponerse en rojo y ejecútala automáticamente en lugar de decidirlo cada vez.