Las pruebas unitarias te dicen que el código funciona para un usuario. En un almacén hay decenas de escáneres confirmando tareas en el mismo segundo, así que escribimos un simulador: operarios de picking, de recepción y supervisores virtuales recorriendo un ciclo completo de pedidos sobre una base de datos real.
Qué medimos
- Más de 16.000 llamadas a la API en una sola ejecución, entre recepción, ubicación, olas, picking, expedición e inventarios.
- Trece invariantes de integridad comprobadas al final: los saldos de stock cuadran con los movimientos, no hay ubicaciones en negativo ni unidades de manipulación huérfanas.
- Percentiles de latencia por llamada, para localizar los puntos lentos.
Qué falló
Las versiones modernas de MariaDB pueden trabajar con aislamiento por instantáneas. En ese modo, si dos escáneres bloquean la misma fila de stock, el segundo no se limita a esperar: recibe un error de registro modificado. Nuestras lecturas con bloqueo tenían que ver el último dato confirmado, y había que bloquear las filas siempre en el mismo orden para evitar interbloqueos.
La conclusión
Pon tu sistema a trabajar como en tu día de más carga antes de que ese día llegue por sí solo. Resultado: cero errores de servidor, todas las invariantes en orden, y desde entonces el simulador se ejecuta tras cada cambio importante.