Corrigir um defeito reproduzindo-o primeiro com um teste que falha

## Decidir a qual parte do sistema o defeito pertence antes de mexer no código Comece pelo impacto observável, não pelo arquivo em que o sintoma apareceu. Um resultado útil de triagem informa à próxima pessoa que investigar o que falhou, quem ou o que foi afetado e qual componente é responsável pelo comportamento. ### Classifique antes de agir - Classifique o defeito como comportamento central, comportamento de sistema ou integração, ou comportamento do ambiente hospedeiro. - Separe o componente que exibe o sintoma do componente que controla o comportamento com falha. - Encaminhe o trabalho para o limite responsável quando as evidências apontarem para fora do componente atual. ### Defina os limites das evidências Registre a entrada que aciona o problema, o estado inicial, as ações exatas do usuário, o resultado esperado, o resultado real e o ambiente relevante. Liste fatos separadamente de hipóteses. Não edite o código de implementação durante a triagem; a próxima etapa deve primeiro estabelecer uma falha reproduzível. A classificação é provisória. Se evidências posteriores a contradisserem, retorne a esta etapa, revise os limites e mova o teste para a camada realmente responsável pelo comportamento. ## Reproduzir o que o usuário vê com um teste que falha Converta o relato no cenário repetível mais curto que ainda corresponda à experiência do usuário. Preserve a entrada, o estado, a sequência e o resultado visível que sejam relevantes; remova preparações incidentais que não afetem a falha. ### Escolha a camada de teste confiável mais próxima - Use um teste unitário ou de componente direcionado para lógica isolada. - Use um teste de integração ou de sistema quando houver persistência, renderização, transporte ou participação de vários componentes. - Use um teste de navegador ou de ponta a ponta quando a falha depender de interação real, foco, temporização, navegação ou estado visual. Escreva o teste de regressão antes de alterar o código-fonte. Execute-o e confirme que ele falha pelo motivo relatado, e não por uma configuração defeituosa, recursos desatualizados, dados ausentes ou uma verificação sem relação com o problema. Um teste que nunca foi observado falhando não é evidência do defeito. Se o comportamento não puder ser automatizado, documente o motivo e capture a alternativa repetível mais sólida, como um procedimento manual determinístico, uma sequência de capturas de tela, um rastreamento ou um resultado medido. Mantenha o código de implementação inalterado até que as evidências da falha sejam confiáveis. ## Encontrar o primeiro ponto em que o comportamento se desvia e isolar a causa raiz Investigue somente depois que a reprodução da falha estiver estável. Formule várias hipóteses plausíveis e teste-as com observações direcionadas, em vez de alterar várias coisas ao mesmo tempo. ### Rastreie a primeira divergência Acompanhe a entrada que falha pelas mudanças de estado, limites e fluxo de controle. Compare um caso bem-sucedido com o caso de falha e encontre o primeiro ponto em que o comportamento real diverge do esperado. Inspecione artefatos gerados, valores persistidos, respostas de integração ou temporização somente onde a reprodução indicar que são relevantes. Para cada hipótese, preveja quais evidências a confirmariam ou rejeitariam, execute a menor verificação capaz de distingui-la e registre o resultado. Diferencie a causa raiz dos danos posteriores e das condições que apenas tornam o defeito mais fácil de observar. Não modifique a lógica de produção enquanto estiver isolando a causa. Se todas as hipóteses falharem, retorne à reprodução, verifique suas premissas, refine a classificação e formule uma nova hipótese apoiada por evidências. ## Aplicar a menor correção e manter o teste para evitar regressões Depois de isolar a causa raiz, altere a menor superfície capaz de restaurar o comportamento pretendido. Preserve os contratos públicos e os comportamentos sem relação com o problema, e evite limpeza, reformulação ou refatoração que o caso de falha não exija. Execute primeiro o teste que falhava originalmente. Agora ele deve passar porque a causa foi removida, não porque a verificação foi enfraquecida, o cenário foi ignorado ou a preparação do teste deixou de acionar o defeito. Mantenha esse teste como proteção permanente contra regressões. Em seguida, execute o grupo de testes diretamente afetado e as verificações estáticas, de estilo ou de tipos relevantes. Amplie para um conjunto maior somente quando a alteração atravessar limites compartilhados ou quando as evidências mais restritas indicarem um risco mais amplo. Trate cada nova falha como evidência: corrija uma regressão real ou retorne ao isolamento da causa raiz se a correção proposta estiver incompleta. Revise o conjunto final de alterações em busca de edições acidentais, lógica duplicada, validações enfraquecidas e casos limítrofes ausentes. Nesta etapa, a correção só está concluída quando o comportamento em questão e as áreas vizinhas diretamente afetadas passam em todas as verificações. ## Repetir os passos do usuário em um ambiente real antes de dar o defeito por corrigido Testes automatizados são necessários, mas não substituem a confirmação do caminho real do usuário. Repita o procedimento original visível ao usuário em um ambiente de execução representativo, usando a mesma entrada e o mesmo estado relevantes que expuseram o defeito. Compare o resultado anterior e posterior no limite visível. Quando aplicável, confirme também o resultado persistido, a apresentação renderizada, o evento emitido, a passagem para a integração ou o artefato reconstruído do qual o usuário depende no fim. Registre o ambiente, as etapas e o resultado observado para que outra pessoa possa verificar a conclusão. Se o comportamento manual ainda falhar, diferir do resultado automatizado ou exigir uma solução alternativa não documentada, não declare que o defeito foi resolvido. Retorne à classificação ou à reprodução, atualize o teste para cobrir a condição ignorada e repita o ciclo de causa, correção, regressão e validação. Encerre com um relatório conciso de evidências: classe do defeito, reprodução confirmada, causa raiz, alteração mínima, cobertura de regressão, verificações diretamente afetadas e resultado do fluxo real. Adicione uma regra reutilizável de prevenção somente quando o defeito revelar uma família arquitetural recorrente; mantenha detalhes pontuais no teste e no histórico de alterações.