Tu suite compara cadenas exactas y tu sistema ya no repite la respuesta
Cuando metes un modelo en el producto, `assertEquals` deja de servir de la noche a la mañana. Lo que funciona es afirmar en tres niveles distintos y medir tasas en vez de resultados sueltos.
Giancarlo Renato Palomino Huallpa
Quality Engineer · Lima, Perú
El día que entra un modelo en el producto, media suite se cae. No porque el código esté mal: porque la misma entrada deja de producir la misma salida, y toda nuestra forma de afirmar se apoyaba justo en lo contrario.
La reacción habitual es una de estas dos, y las dos son malas. O se marca el módulo como «no automatizable» y se revisa a ojo, o se escribe una comprobación tan laxa —que la respuesta no esté vacía— que pasa siempre y no comprueba nada.
Hay una tercera, que es la que uso.
Qué sigue siendo determinista
Antes de nada: no todo cambia. Y lo que no cambia hay que seguir exigiéndolo con la misma dureza de siempre, porque es donde se cuelan los defectos aburridos y caros.
Esto no varía aunque el texto sí
Esto es más de lo que parece. En la mayoría de integraciones que he visto, el 80 % de lo que puede ir mal está en esta tabla, no en si la redacción fue afortunada.
Los tres niveles de afirmación
Para lo que sí varía, no hay una técnica: hay tres, y se usan a la vez.
De lo más duro a lo más blando
El nivel dos es el que cambia la vida. En vez de comprobar qué respondió, compruebas qué tiene que ser verdad de cualquier respuesta válida:
- Si el usuario preguntó por su saldo, el importe que aparezca tiene que ser el que hay en la base de datos. El texto da igual.
- Si la pregunta era sobre devoluciones, la respuesta tiene que citar la política de devoluciones y no la de envíos.
- Si no hay datos para contestar, tiene que decir que no lo sabe, y no debe aparecer ninguna cifra.
Fíjate en que ninguna de las tres compara textos. Son afirmaciones sobre hechos, y los hechos no varían con la redacción.
El nivel tres —comparar significados— es el último recurso, no el primero. Cuesta más, es más frágil y, sobre todo, necesita que alguien decida qué es «lo mismo».
El conjunto de referencia
Para medir hace falta un conjunto de casos con su respuesta aceptable. Es el equivalente a tu suite de regresión, y montarlo es el trabajo de verdad.
Cómo lo construyo
El tercer paso merece insistencia. Un conjunto solo con preguntas contestables mide si el sistema responde bien. No mide si sabe callarse, y el fallo caro casi siempre es ese: inventarse una respuesta en vez de decir que no tiene el dato.
Medir tasas, no resultados
Y aquí está el cambio mental grande: con un sistema no determinista, una ejecución no dice nada.
La misma prueba, dos formas de leerla
Como una prueba normal
Se ejecuta una vez
Pasa o falla
Si falla, se vuelve a lanzar «por si acaso»
Esto es echar una moneda al aire y anotar el resultado.
Como una medición
Se ejecuta n veces
Se mide la tasa de acierto
El umbral es la tasa, no el caso
«Este caso acierta el 96 % de las veces» sí es información.
Eso cambia cómo se escribe el umbral. En vez de «este caso debe pasar», es «el conjunto debe acertar por encima del 95 %, y ningún caso crítico puede bajar del 100 %». Los casos críticos —los de dinero, los de datos personales— no admiten tasa: o siempre, o no sale.
Y da un efecto secundario muy útil: si una tasa cae de un día para otro sin que hayas tocado nada, el modelo cambió debajo. Eso pasa, y sin medir tasas no te enteras hasta que lo nota un cliente.
La trampa de aceptar varianza donde no la hay
Lo que más me encuentro al revisar estas integraciones: equipos que, al descubrir que el sistema no es determinista, aflojan todo.
Dónde aflojar y dónde no
Varía de verdad
La redacción, el orden de los argumentos, la longitud. Aquí van propiedades y semántica.
No varía
El importe, el identificador, la decisión de sí o no. Aquí va igualdad exacta.
El error común
Comprobar que «la respuesta contiene un número». Pasa siempre, no comprueba nada.
Lo que hay que hacer
Extraer el dato de la respuesta y compararlo con la fuente. Eso sí es determinista.
La tercera celda es un caso real que he visto más de una vez. Comprobar que hay un número no distingue entre el saldo correcto y uno inventado. Lo que hay que hacer es sacar el número y compararlo con la base de datos, y eso vuelve a ser una comprobación de toda la vida.
Resumido: cuando entra un modelo, no se relaja la suite. Se reparte en dos.
La mitad determinista —forma, tipos, efectos, datos concretos— sigue siendo tan dura como antes, y ahí está la mayoría de lo que puede salir mal. La otra mitad deja de preguntarse «¿dijo exactamente esto?» y pasa a preguntarse «¿es verdad lo que dijo, y acierta con la frecuencia que acordamos?».
Lo difícil no es la técnica. Es aceptar que ahora tu suite devuelve un porcentaje, y que alguien tiene que decidir cuál es el aceptable.