Gerenciando a regressão

Question

Sou um codificador impulsivo por natureza e comecei a aprender a virtude da paciência da maneira mais difícil da programação. Uma das áreas que me saio mal é quando estou modificando o código existente. Se eu não tiver todos os detalhes estabelecidos antes de mim, invariavelmente sinto falta de certas avenidas que às vezes levam à regressão. Estou bem na codificação, mas subestimou a manutenção do código até ler "padrões de implementação".

Então, minha pergunta é se você está mantendo o código existente, como cobre todas as bases e garante que não esteja deixando buracos para trás? Quais são as estratégias que você usa quando não tem certeza de onde o código pode quebrar?

Answer 1

Testes de unidade, em breve. Você precisa de cobertura de teste para garantir que, quando fizer alterações, poderá executar novamente os testes e garantir que você não quebrou nada.

Se você tiver uma integração contínua, isso aparecerá como/quando você fizer o check -in. Eu fiz o check -in precoce/frequentemente Para garantir que suas alterações sejam pequenas e que você possa rastrear facilmente as causas dos bugs.

A dor de cabeça está adaptando os testes de unidade para uma estrutura já existente. Você provavelmente terá que reengenharia parte da biblioteca existente para permitir Injeção de dependência e zombando. Infelizmente, apenas fazer essas alterações não deixa de ter seus riscos, e isso aponta para escrever os testes (e projetar seu código para ser amigável) o mais cedo possível.

Answer 2

Se você pode descobrir alguns casos de borda, pode escrever alguns testes de unidade. Então, após as modificações, você pode verificar se seus testes ainda passam.

Não é à prova de idiotas, mas é melhor do que nada!

Answer 3

Teste de unidade, em poucas palavras. Um dos benefícios da redação de testes de unidade é que ele pode tornar a refatoração/alterações posteriores do código mais seguras e dar mais confiança de que essas mudanças não quebraram nada.

Amarre isso a um ambiente de integração contínua, onde o código mais recente é retirado periodicamente do controle de origem, construído e, em seguida, todos os testes de unidade são executados, e você terá feedback bem rápido de maneira automatizada se algum código for interrompido.