Una prueba que fallaba una de cada tres veces (y el código estaba bien)

El problema: ocho piezas en vez de tres

Teníamos publicaciones duplicadas. En la cola de publicación había ocho piezas donde debía haber tres. El botón de aprobar no se bloqueaba al pulsarlo: varias aprobaciones llegaban a la vez, todas comprobaban que la pieza seguía pendiente y todas la programaban.

El arreglo era el habitual en estos casos: un cambio de estado atómico. Sólo quien llega primero consigue la pieza; el segundo se queda sin ella y no duplica nada.

Hasta aquí, nada fuera de lo normal. El problema vino después, al comprobar que el arreglo funcionaba de verdad.

Una prueba que no se fiaba de sí misma

Lanzamos la prueba del arreglo varias veces seguidas. Y fallaba una de cada tres.

La primera sospecha, razonable, fue que el cerrojo tenía un agujero: que en algún caso raro, dos procesos aún podían colarse a la vez y quedarse con la misma pieza.

Pero el cerrojo estaba bien. El problema estaba en cómo habíamos montado la prueba: usábamos una base de datos en memoria para probar rápido, y todos los hilos de la prueba compartían una misma conexión a esa base de datos. Cuando un hilo deshacía su operación (una marcha atrás, un rollback), arrastraba con él el cerrojo que había puesto otro hilo distinto. La prueba se saboteaba a sí misma.

La comprobación que lo confirmó

Cambiamos la prueba para que cada hilo tuviera su propia conexión, igual que ocurre en producción, donde cada proceso habla con la base de datos por su cuenta.

Con una conexión por hilo, la prueba pasó quince de quince veces.

El código nunca había estado mal. Lo que fallaba era el banco de pruebas: al compartir una conexión entre hilos, estábamos probando un escenario que no existe fuera de ese entorno simplificado. Una prueba inestable no siempre apunta a un fallo real; a veces apunta a que la prueba no reproduce las condiciones que dice reproducir.

Esto nos deja una regla sencilla para la próxima vez que una prueba falle sin motivo aparente: antes de tocar el código que se está probando, hay que preguntarse si el entorno de prueba se parece de verdad a producción. Si comparte recursos que en producción están separados, el fallo puede estar ahí.

Qué nos llevamos

Una prueba que falla a veces no es automáticamente un aviso de bug: puede ser un aviso de que la propia prueba simplifica demasiado. En este caso, igualar el entorno de prueba al de producción —una conexión por hilo— bastó para que el resultado fuera estable y confiable.

Fuente de las cifras: Laboratorio de Kalmia Zen, 10/2026.