Pedir pruebas a la IA y comprobar que sirven
Una prueba que nunca falla no sirve de nada. Aprende a escribir pruebas mínimas sin herramientas, a pedírselas a la IA con los casos y resultados que tú decides, y a romper el código a propósito para ver si las pruebas lo detectan.
Una prueba compara lo que devuelve tu código con lo que debería devolver; te avisa si al refactorizar o al usar un agente se rompe algo.
Los resultados esperados los decides tú, a mano. Si los calcula la IA (o tu propio código), la prueba copia el fallo en lugar de detectarlo.
Pide pruebas para el caso normal, el caso vacío o raro y el límite (50 y 49,99, no solo 80 y 20).
Desconfía de las pruebas que comparan la función consigo misma o solo comprueban que «devuelve algo».
- Te avisan cuando algo deja de hacer lo que debía.
- Una prueba es un trozo de código que llama a tu función con una entrada concreta y comprueba que el resultado es el esperado. Si mañana tú, un compañero o un agente cambiáis la función y rompéis algo, la prueba lo dice en el momento.
- En la lección de refactorizar usaste console.assert. Aquí darás un paso más: un pequeño ayudante que enseña ✅ o ❌ para cada caso y que te servirá para pedir y revisar pruebas generadas por la IA.
- Una función de cinco líneas basta para empezar.
- La función probar(nombre, real, esperado) compara con Object.is (como ===, pero también trata bien NaN) y escribe el resultado. Así cada prueba es una línea legible: qué compruebas, qué sale y qué debería salir.
Para qué sirve una prueba
Te avisan cuando algo deja de hacer lo que debía.
Una prueba es un trozo de código que llama a tu función con una entrada concreta y comprueba que el resultado es el esperado. Si mañana tú, un compañero o un agente cambiáis la función y rompéis algo, la prueba lo dice en el momento.
En la lección de refactorizar usaste console.assert. Aquí darás un paso más: un pequeño ayudante que enseña ✅ o ❌ para cada caso y que te servirá para pedir y revisar pruebas generadas por la IA.
Una prueba mínima, sin herramientas
Una función de cinco líneas basta para empezar.
La función probar(nombre, real, esperado) compara con Object.is (como ===, pero también trata bien NaN) y escribe el resultado. Así cada prueba es una línea legible: qué compruebas, qué sale y qué debería salir.
En proyectos reales se usa un ejecutor de pruebas como Vitest (npm run test), que hace lo mismo con más ayudas. La forma de pensar las pruebas es idéntica.
Pedir pruebas a la IA: los casos y los resultados los pones tú
Tú decides qué deben comprobar.
Un buen encargo de pruebas lista los casos con su resultado esperado, calculado por ti: «Escribe pruebas con probar() para descuento(): 80 → 8, 20 → 0, 50 → 5 (el límite), 49.99 → 0 y 0 → 0. No cambies la función.»
Si dejas que la IA invente los resultados esperados, los sacará de leer tu código: si el código tiene un fallo, la prueba lo copiará y saldrá ✅. Por eso el «qué debería pasar» tiene que venir de ti (o del enunciado), no de la implementación.
Pruebas que no prueban nada
Tres trampas habituales en las pruebas generadas.
- Tautológicas: comparan la función consigo misma (probar('x', descuento(80), descuento(80))). Siempre pasan.
- Que solo miran la forma: «devuelve un número», «no da error». Una función que devuelve siempre 0 las aprueba.
- Con el esperado copiado del código: si el valor esperado se calcula con la misma fórmula que la función, repiten su fallo.
Rómpelo a propósito
Así sabes si tus pruebas detectan los fallos.
Cambia la función a mal adrede: >= por >, 0.1 por 0.2, quita el trim(). Ejecuta las pruebas. Si alguna pasa a ❌, bien: te protege de ese error. Si todas siguen en ✅, te falta una prueba para ese caso; escríbela y deshaz el cambio.
Esta técnica (en grande se llama mutation testing) es especialmente útil con pruebas generadas por IA: en un minuto descubres si cubren los límites o solo el caso cómodo.