Pruebas de software, explicadas para quien nunca las escribió

Cada vez que alguien cambia un software, algo que funcionaba puede dejar de funcionar sin hacer ruido. Una nueva regla de descuento rompe el pago. Una búsqueda más rápida pierde la mitad de los resultados. Nadie se da cuenta hasta que lo nota un cliente.

Las pruebas son la forma en que el equipo se da cuenta primero. No necesitas escribirlas para entenderlas, y si estás construyendo con una herramienta de IA, entenderlas importa más que nunca.

Qué es una prueba

Una prueba es un pequeño fragmento de código que revisa una sola cosa y responde sí o no. “Si un cliente pide dos productos de $10, el total es $20.” “Si la contraseña es incorrecta, se rechaza el ingreso.” Corre sola, cada vez que cambia el código, en segundos.

Piensa en la lista de chequeo de un piloto antes de despegar. El piloto sabe volar. La lista existe porque las personas olvidan, y olvidar un punto sale caro. Las pruebas son la lista de chequeo que tu software se aplica a sí mismo antes de cada publicación.

Por qué importan más cuando la IA escribe el código

Las herramientas de IA cambian el código rápido, y muchas veces en varios lugares a la vez. Pides un arreglo pequeño y la herramienta además “ordena” otros tres archivos. Quien revisa puede pasar por alto lo que se tocó. Las pruebas no se cansan ni leen por encima. Si el “orden” rompió el total de la factura, la prueba de la factura falla, y te enteras antes que tus clientes.

Las pruebas también le dan retroalimentación a la herramienta de IA. Muchos asistentes de programación pueden correr las pruebas por su cuenta, ver qué falló y corregirlo. Sin pruebas, la herramienta adivina si su cambio funcionó, y tú también.

Los tipos, en palabras simples

• ¿Funciona esta pieza? Revisa una parte pequeña por separado, como la función que calcula el impuesto. Los ingenieros les dicen pruebas unitarias. Son rápidas y baratas, así que puedes tener cientos.
• ¿Funcionan estas piezas juntas? Revisa que dos partes se comuniquen bien, como tu app guardando un pedido en la base de datos. Son pruebas de integración.
• ¿Funciona el flujo completo? Actúa como un usuario real: abre el sitio, se registra, compra algo, recibe el correo. Son pruebas de punta a punta. Son más lentas y frágiles, así que ten pocas, para los flujos clave.

Las pocas pruebas con las que empezar

Si un proyecto no tiene pruebas, no intentes cubrirlo todo. Apunta a los lugares donde una falla cuesta dinero o confianza:

1. El camino del dinero. Precios, totales, pagos, facturas.
2. La entrada. Registro, inicio de sesión, recuperación de contraseña.
3. Quién ve qué. Un cliente nunca debe ver los datos de otro.
4. La tarea principal. Lo único a lo que vienen los usuarios, de principio a fin.
5. Cada error que arreglas. Cuando algo falla, agrega una prueba que lo habría detectado, para que no vuelva sin que nadie lo note.

Después haz que las pruebas corran automáticamente con cada cambio, y que una prueba fallida bloquee la publicación. Una prueba que nadie corre no protege nada.

Cómo pedirle a una herramienta de IA que las escriba

Sé específico. “Escribe pruebas” te da pruebas que pasan. Eso no es lo mismo que pruebas que revisan.

• “Escribe pruebas para el total del pedido: un pedido normal, un carrito vacío, un descuento, un reembolso. Incluye casos que deban rechazarse.”
• “Prueba que un usuario de la empresa A nunca pueda leer los registros de la empresa B.”
• “Antes de escribir pruebas, haz una lista de lo que este código debe hacer, para que yo la confirme.”

Esa última es la más importante. Si la herramienta escribe las pruebas solo a partir del código, va a probar lo que el código hace, errores incluidos. Las pruebas deben describir lo que el código debería hacer, y eso solo lo puedes confirmar tú.

Cómo revisar que las pruebas no sean de mentira

Las herramientas de IA a veces escriben pruebas que aparentan mucho y no revisan nada, o cambian una prueba en silencio hasta que pasa. Busca esto:

• Rómpelo a propósito. Cambia un número en el código, como una tasa de impuesto, y corre las pruebas. Si nada falla, ninguna prueba está vigilando ese número.
• Lee los nombres. Los nombres de las pruebas deberían leerse como frases sobre el comportamiento: “rechaza el ingreso con contraseña incorrecta”. Nombres vagos como “prueba 1” suelen esconder revisiones vagas.
• Busca el sí o no. Cada prueba debe comparar un resultado con un valor esperado. Una prueba que solo ejecuta el código sin revisar el resultado siempre va a pasar.
• Ojo con las expectativas editadas. Si un cambio hizo fallar una prueba y el “arreglo” fue cambiar la respuesta esperada, pregunta por qué. A veces es lo correcto. Muchas veces esconde un error.
• Cuenta las pruebas omitidas. Las pruebas marcadas como “skip” no corren. Cada omitida es un punto ciego.