Probar que un nombre no cruza la puerta

Si mandas datos de tus clientes a un proveedor de inteligencia artificial, esta nota es sobre la única clase de prueba que de verdad te protege, y sobre los cuatro casos que hay que escribir.

Casi todas las pruebas de un programa comprueban cosas reversibles. Si una falla en producción, se arregla y se vuelve a intentar. El cálculo estaba mal, ahora está bien.

Hay una clase que no funciona así. Cuando el sistema manda a un proveedor ajeno el cuerpo literal de lo que escribió un cliente, eso, una vez sale, no vuelve. No hay corrección posible.

Lo que se escape en esta prueba se escapó de verdad. Por eso es la que vale.

La consecuencia práctica es que esa prueba merece un tratamiento distinto: se escribe primero, va aparte, y la pieza que comprueba está diseñada para poder probarse sin levantar nada.

Lo difícil de estas pruebas no es escribirlas: es acordarse de los casos. Y los casos no salen de imaginar ataques, salen de leer conversaciones de verdad.

El segundo es el que se olvida siempre. Uno piensa en el nombre —porque el nombre está en un campo, en una columna, a la vista— y el teléfono no está en ningún campo: está dentro del texto, escrito por la propia persona para que la llamen.

Lo mismo con la cédula. Nadie tiene una columna de cédula. La gente la escribe en el chat cuando se la piden para una factura.

Estas pruebas tienen una forma poco común y conviene entenderla, porque es lo que las hace fiables.

Una prueba normal comprueba que el resultado es lo esperado. Estas comprueban que el resultado no contiene algo. Es más débil por naturaleza: hay infinitas formas de que un dato se cuele.

Por eso se comprueban las dos caras: que el nombre no está, y que en su lugar aparece la ficha que debía sustituirlo. Si solo comprobaras la ausencia, una función que devolviera una cadena vacía pasaría la prueba con matrícula de honor.

Y para el teléfono no se busca el número exacto, sino cualquier tira de siete cifras seguidas, quitando antes los espacios. Buscar el número tal cual dejaría pasar «3001234567» si la prueba escribió «300 123 4567».

Es la regla general de probar ausencias: busca la forma, no el valor. El valor concreto es el único que seguro no se te va a colar.

Hay una decisión de arquitectura detrás de todo esto, y es anterior a las pruebas.

Lo que tapa los datos vive en un archivo que no toca la base de datos ni la sesión. Recibe un texto y devuelve un texto.

Eso permite probarlo entero con el sistema de pruebas normal, en segundos, sin levantar servidor ni preparar datos. Y como cuesta segundos, se ejecuta siempre: en cada cambio, en cada integración.

Si estuviera enredado con el resto —leyendo de la base, dependiendo de quién ha iniciado sesión— probarlo exigiría montar un entorno. Y lo que exige montar un entorno se prueba de vez en cuando, que en la práctica significa nunca cuando hay prisa, que es exactamente cuando se rompen estas cosas.

Una comprobación que tarda minutos se ejecuta cuando hay tiempo. Las que importan tienen que tardar segundos.

Hay que decirlo, porque una prueba que se cree infalible es peor que ninguna.

Un filtro de datos personales no puede ser completo. Reconoce formas: tiras de dígitos, direcciones de correo, los nombres que conoce. No reconoce «el de la ferretería de la esquina de mi casa», que identifica a alguien perfectamente.

Por eso el filtro es una capa y no la única. Encima están: no mandar nada a modelos que entrenan con lo recibido, limitar cuánta conversación se manda, y que una persona lea el borrador antes de que salga.

Lo que estas pruebas sí garantizan es que los casos que ya conocemos no vuelvan a colarse. Que es el trabajo de una prueba: no descubrir fallos nuevos, sino impedir que vuelvan los viejos.

• Identifica qué de tu sistema es irreversible. Lo que sale hacia fuera y no vuelve. Esa lista es tu lista de pruebas prioritarias.
• Saca los casos de conversaciones reales. No de imaginar ataques. El teléfono dentro del texto no se le ocurre a nadie en una pizarra.
• Comprueba las dos caras. Que el dato no está y que la sustitución sí. Si no, una función rota pasa la prueba.
• Busca la forma, no el valor. Siete cifras seguidas, no el número que escribiste tú.
• Haz que la pieza sensible se pueda probar sola. Si probarla exige montar un entorno, no se va a probar los días de prisa.