Utilidades IACómo escribir pruebas automáticas con ayuda de la IA
| Para quién | Para quien programa y quiere ampliar la cobertura de pruebas de una función, un módulo o una pequeña aplicación, tanto si empieza con las pruebas como si ya tiene experiencia. |
|---|---|
| Tiempo estimado | Entre 30 y 60 minutos por función o módulo pequeño, incluida la revisión de los tests. |
| Categoría | Programación y datos |
Paso a paso
- Escoge una unidad pequeña y bien definida
Empieza por una función con entradas y salidas claras, sin dependencias de red ni de bases de datos. Anota en lenguaje natural qué debe hacer, qué entradas admite y qué debe ocurrir ante entradas inválidas. Esa descripción es la especificación y es lo que realmente se está probando. Si no sabes explicar el comportamiento esperado, el asistente lo deducirá del código, y entonces los tests solo reflejarán lo que ya hace la función, incluidos sus errores. Conviene redactar la especificación antes de enseñar la implementación. - Pide primero una lista de casos, no el código
Solicita al asistente una tabla de casos de prueba: entradas típicas, valores límite, entradas vacías o nulas, tipos inesperados y combinaciones raras. Pide que indique, para cada caso, el resultado esperado y el motivo. Revisa esa lista antes de pasar al código: añade los casos que conozcas por experiencia, como errores pasados, y descarta los redundantes. Pensar los casos es la parte con más valor, y es donde tu conocimiento del problema supera al de cualquier modelo. - Genera los tests con el marco que ya usas
Indica el lenguaje, la versión y el marco de pruebas que usa tu proyecto, y pide un test por caso con nombres descriptivos que expliquen la situación. Solicita que cada prueba compruebe una sola cosa y que no dependa del orden de ejecución. Si hay datos de ejemplo, pide que sean inventados y mínimos. Evita que el asistente use imitaciones complejas de dependencias en esta fase: cuanto más sencillos sean los tests, más fácil será entender por qué fallan cuando lo hagan. - Ejecuta los tests y analiza cada fallo
Ejecuta la batería completa. Si alguna prueba falla, no pidas de inmediato al asistente que la arregle: primero decide si el fallo está en el test, en el código o en la especificación. A veces el asistente se equivoca al calcular el resultado esperado. Otras veces el fallo destapa un error real, que es justamente para lo que sirven las pruebas. Corrige solo cuando entiendas la causa, y deja anotado el motivo de cada decisión en un comentario o en el mensaje del cambio. - Comprueba que los tests detectan errores
Un test que siempre pasa no vale nada. Introduce deliberadamente pequeños fallos en una copia del código, como cambiar un operador de comparación, quitar una validación o alterar un límite, y confirma que algún test falla. Si ninguno lo hace, faltan casos o las comprobaciones son demasiado débiles. Puedes pedir al asistente que sugiera qué errores plausibles introducir, pero la ejecución real es la que da la respuesta. Esta técnica revela pruebas decorativas que aumentan la cobertura sin proteger nada. - Integra, documenta y mantén la batería
Incorpora los tests al repositorio y a tu flujo habitual de integración, si lo tienes, para que se ejecuten con cada cambio. Elimina duplicados y comentarios innecesarios que haya generado el asistente, y asegúrate de que el estilo sea coherente con el resto del proyecto. Anota qué casos quedan sin cubrir y por qué. Revisa la batería cuando cambie la especificación, porque unos tests desactualizados generan una falsa sensación de seguridad que es peor que no tener ninguno.
Prompt de ejemplo
Rellena los corchetes con tu caso antes de pegarlo en un asistente:
Eres un ingeniero de calidad que explica con claridad. Voy a probar la función [NOMBRE DE LA FUNCIÓN] escrita en [LENGUAJE] con el marco [MARCO DE PRUEBAS]. Su comportamiento esperado es: [DESCRIPCIÓN EN LENGUAJE NATURAL]. Entradas válidas: [DESCRIPCIÓN]. Entradas inválidas y qué debe pasar: [DESCRIPCIÓN]. Paso 1: dame una tabla de casos con entrada, resultado esperado y motivo, incluyendo valores límite y entradas raras. No escribas código todavía. Cuando yo apruebe la tabla, escribiré el código de los tests. Señala cualquier ambigüedad de mi especificación en vez de suponer, e indica qué casos no has podido cubrir.
Qué esperar
Obtendrás una lista de casos razonablemente completa y, después, un conjunto de tests legibles. Es habitual que haya algún resultado esperado mal calculado, casos repetidos y comprobaciones demasiado flojas. El asistente es útil para no olvidar escenarios, pero la decisión de qué es correcto sigue siendo tuya.
Cómo verificar el resultado
- Ejecuta todos los tests y revisa uno a uno los fallos para decidir si el error está en el test o en el código.
- Introduce errores deliberados en una copia del código y confirma que al menos un test falla en cada caso.
- Comprueba a mano el resultado esperado de varios casos límite sin fiarte de lo que dice el asistente.
- Revisa que los tests no dependen del orden, de la fecha del día ni de datos externos.
Errores comunes
- Pasar al asistente solo el código y dejar que deduzca el comportamiento, con lo que los tests confirman los errores existentes.
- Dar por buena una cobertura alta sin comprobar que los tests fallan cuando el código se rompe.
- Pedir al asistente que arregle los tests fallidos sin entender si el fallo era real.
- Generar muchas pruebas de golpe y no revisar duplicados, nombres confusos ni dependencias ocultas.
Riesgos y límites
El asistente puede calcular mal resultados esperados, inventar funciones del marco de pruebas que no existen o escribir comprobaciones tan débiles que nunca fallan. También tiende a replicar la lógica del código dentro del test, con lo que ambos comparten el mismo error. No sustituye al análisis de requisitos ni a las pruebas de integración, de rendimiento o de seguridad. Si el código maneja datos sensibles, no lo pegues en la conversación sin comprobar la política de tu organización. Los tests deben revisarse con el mismo rigor que el código de producción.
Preguntas frecuentes
¿La IA puede garantizar que mi código no tiene errores?
No. Las pruebas, sean humanas o generadas, solo demuestran la presencia de fallos en los casos probados, nunca su ausencia total. Un asistente ayuda a ampliar los casos, pero es imprescindible revisar que los tests sean correctos y que detecten errores reales.
¿Debo pasar todo mi proyecto al asistente?
No es necesario ni prudente. Comparte la función o el módulo concreto, sin secretos ni datos reales, junto con la especificación. Cuanto más acotado sea el encargo, más fácil es revisar la respuesta y menor es el riesgo de exponer información.
¿Qué tipo de pruebas conviene pedir primero?
Las pruebas unitarias de funciones puras son las más sencillas de generar y de verificar. Después puedes pasar a pruebas de integración, que requieren más contexto sobre el entorno. Avanza por etapas y revisa cada una antes de seguir.