Quantos erros de regressão da refatoração são muitos.

4

Testes recentes de controle de qualidade encontraram alguns erros de regressão em nosso código. Meu líder de equipe culpa os recentes esforços de refatoração para as regressões.

A postura do meu time é "refatorar, mas não quebrar muitas coisas", mas não me diria quantos são "demais". Minha postura é o trabalho do QA para encontrar bugs que não conseguimos encontrar, e a refatoração geralmente introduz mudanças inesperadas. Então, com certeza, posso ser cuidadoso, mas não liberei o código com problemas para o controle de qualidade. Eu faço porque não os vejo.

Se a refatoração foi necessária, quantos erros de regressão devem ser considerados muitos?

    
por John Doe 05.04.2013 / 02:49
fonte

2 respostas

22

Você está certo de que o código de refatoração é importante. Isso evita a podridão do código e melhora o código. Faz um código mais limpo.

Mas um código bom não é apenas um código limpo, é um código correto e, portanto, por definição, contém o mínimo de erros possível (idealmente nenhum). O primeiro objetivo do seu código é produzir o resultado esperado. Então, se a sua refatoração estiver introduzindo bugs, você pode querer considerar o efeito líquido dessas refatorações.

Você deve refatorar o código que é testado. Se não estiver, adicione testes e refatorie. Dessa forma, você sabe que não quebrou nada. Isso ajudará a reduzir os riscos de uma situação semelhante acontecer no futuro.

Quanto à refatoração da introdução de bugs, a refatoração não deve alterar o comportamento de um programa. Vou citar Wikipedia :

disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior

Infelizmente, atualmente, a refatoração passou a significar qualquer coisa, desde essa definição até o total reescreve.

Eu alteraria o que seu líder de equipe disse:

refactor but don't break too many things

Para:

refactor and don't break anything

Quanto a encontrar erros sendo o trabalho do QA, a qualidade não é problema de outra pessoa. O objetivo deve ser que o controle de qualidade não encontre nada. Realisticamente encontrar o mínimo possível.

    
por 05.04.2013 / 04:56
fonte
13

My stance is it's QA's job to find bugs that we can't find,

Encontrar erros é uma responsabilidade conjunta.

O trabalho do QA é encontrar bugs que você não encontra. Não deve haver erros que você não pode encontrar. (E se houver, então talvez você devesse pedir acesso às ferramentas / testes que eles estão usando para que você possa encontrá-los por si mesmo.

refactoring usually introduces breaking changes.

Isso não é verdade. A refatoração feita corretamente não quebra as coisas. E você poderia argumentar que consertar as coisas que quebram deve fazer parte da refatoração.

Os problemas surgem na realidade quando:

  • a refatoração aciona bugs latentes em outras partes da base de código que os testes que você pode executar não revelam ou

  • você não pode fazer o refator completo porque outra pessoa "possui" algumas partes do código afetadas pelo refatorador.

Você não deve ser culpado por bugs latentes (a menos que eles fossem seus em primeiro lugar). Mas, por outro lado, se sua refatoração estiver alterando intencionalmente APIs e / ou comportamentos, será necessário discutir isso com todas as partes antes de refatorar e ter um plano para lidar com os efeitos. Na terceira mão 1 , se a mudança for inesperada ou acidental ... então você deve ter pensado nisso com mais detalhes.

E, finalmente, se as regressões foram culpa sua (ou, em parte, culpa sua), então "suba" e leve a culpa. E vise fazer melhor da próxima vez.

If he agrees that refactoring is necessary (which he does), then why does he have a problem when stuff breaks? Especially when it hasn't affected our schedule so far.

Isso é fácil de responder se você se colocar no lugar dele. Ele acha que você fez a coisa errada da maneira como você refatorou o código. Desta vez, isso não afetou o cronograma. Mas da próxima vez, poderia. Ele está tentando impedir essa eventualidade.

1 - Uma alusão de Larry Niven.

    
por 05.04.2013 / 04:59
fonte