Ferramentas de debugging por categoria, e o que cada uma pressupõe
Depuradores passo a passo e inspetores
Pausam a execução e deixam você olhar o estado.
Pressupõem que você consegue disparar a falha sob demanda.
Logs e tracing
Mostram o que aconteceu depois do fato, inclusive em produção.
Pressupõem que você logou a coisa certa antes.
Profilers
Mostram para onde vai o tempo ou a memória.
Pressupõem que o problema é de recursos.
Todas elas pressupõem que você já chegou até a falha. É nessa pressuposição que as horas realmente vão embora.
A etapa que falta
Uma reprodução confiável é o artefato de maior valor no debugging e o que tem menos chance de existir. Sem ela você está chutando; com ela, todas as outras ferramentas passam a funcionar de imediato.
O que torna uma reprodução confiável é ela estar escrita como passos com um resultado esperado, e não guardada na cabeça de alguém. Escrita, ela pode ser executada de novo, repassada para outra pessoa e mantida depois da correção.
Por que isso pesa ainda mais com um agente de código
Quando quem corrige é um agente, uma descrição vaga é muito pior do que seria para uma pessoa. Um humano consegue inferir o que você quis dizer a partir de um screenshot. Um agente precisa da sequência e da divergência ditas de forma explícita e, com qualquer coisa menos que isso, vai corrigir a coisa errada com toda a confiança.
A ordem em que vale a pena testar
Diante de um bug que você não consegue explicar de imediato, existe uma sequência que converge mais rápido do que seguir a sua primeira hipótese, principalmente porque a sua primeira hipótese costuma ser sobre o código e a resposta muitas vezes não está lá.
Acontece a partir de um estado completamente limpo. Se não, é estado residual e nada no código está errado do jeito que você imagina.
Acontece em outro ambiente. Se não, a diferença entre os ambientes é o bug, e você pode parar de ler o diff.
Acontece todas as vezes. Se não, é timing ou concorrência, o que descarta a maioria das explicações determinísticas que você estava prestes a testar.
Três perguntas, alguns minutos, e cada resposta elimina uma classe inteira de causa. A maior parte do tempo gasto com debugging vai para explorar uma classe que uma dessas perguntas teria descartado na hora.
Guarde a reprodução depois
O caso que você montou para enxergar o bug é a verificação que impede que ele volte. A maioria dos times apaga esse caso junto com a branch, e é por isso que o mesmo defeito reaparece seis meses depois e ninguém reconhece.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
A mesma configuração está disponível no dashboard do TestSprite, caso você prefira não instalar nada localmente. O resto do que o CLI oferece está no repositório do CLI.
O GitHub App é um webhook que você configura no dashboard do TestSprite. Ele escuta o evento de deployment que seu pipeline já produz, então nada no seu repositório muda.
GitHub Actions coloca a etapa dentro do seu próprio workflow, configurada pelo terminal.
Como o TestSprite entrega a etapa que falta
Ele transforma uma reprodução em artefato. Você descreve a sequência e o que deve ser verdade no final, e ele executa contra a sua aplicação em deploy e relata o que realmente aconteceu. Essa é a etapa que todas as outras ferramentas de debugging pressupõem que você já tem.
A instalação coloca a skill de verificação dentro do seu agente de código, para que ele mesmo produza e leia essa evidência em vez de esperar que você repasse. Para um bug intermitente, rodar o mesmo caso várias vezes te dá uma taxa, o que restringe a causa muito mais rápido do que mais uma hipótese.
E a reprodução sobrevive à correção. Ela fica no projeto e roda a cada mudança, então o mesmo defeito não consegue voltar silenciosamente depois que a branch é mergeada e a conversa já acabou.
Qual é a ferramenta de debugging mais subestimada?
Uma reprodução escrita. Custa cinco minutos e faz todo o resto funcionar.
Como eu faço debug de algo intermitente?
Execute a mesma sequência várias vezes e registre a taxa. Uma falha a cada quatro execuções costuma ser timing ou estado residual, o que restringe bastante as possibilidades.
Logs são suficientes?
Eles contam o que o código decidiu, não o que o usuário vivenciou. A lacuna entre essas duas coisas é onde mora boa parte dos defeitos.
Um agente consegue fazer debug por mim?
Ele consegue propor causas e correções. Ele não consegue observar a aplicação em execução a menos que algo lhe dê essa capacidade, e é justamente essa a etapa que falta na maioria das configurações.
O que eu devo fazer primeiro com um bug novo?
Reproduza o bug e escreva a sequência. Tudo depois disso fica mais rápido, inclusive pedir ajuda para outra pessoa.
A reprodução é a ferramenta.
Ferramentas de debugging pressupõem que você já consegue disparar a falha, e é chegar até lá que consome o tempo. Escreva a reprodução, guarde ela depois da correção e entregue a quem for corrigir a sequência e a divergência, em vez de uma descrição.