Devo escrever um teste para provar que a exclusão do código corrige um erro?

Ocasionalmente, encontro a situação em que a correção de um bug exige que eu exclua uma seção do código. O purista do TDD (suponho) defenderia a gravação de um teste com falha, a exclusão do código e a observação do teste.

Agora, parece realmente estranho ter um teste afirmando que algum código foi removido. Claro, suponho que isso garantiria que ninguém investigasse o controle de origem e colocasse esse código de volta, mas vale a pena? Se vale a pena, certamente parece menos valioso do que escrever um teste para o código que foi adicionado , certo?

unit-testing tdd bug

— jhewlett
fonte

Eu acho que qualquer teste de regressão é útil, independentemente de como o bug foi corrigido

— Ismail Badawi

O teste não assert o código foi removido - o teste afirma o bug é fixa ...

— user253751

Você está olhando da maneira errada. O teste não afirma que o código foi removido. O ensaio faz valer uma determinada funcionalidade.

O teste não se importa com a quantidade de código necessária para fazê-lo passar, nem percebe que você removeu algum código. O valor de ter esse teste é o mesmo que qualquer outro teste que você criar devido a um erro: você confia na ausência do erro quando o teste passa e a integração do teste no processo de criação garante que o erro ocorra. provavelmente não será reintroduzido.

Contudo uma outra maneira de olhar para ele a partir de uma perspectiva TDD é o seguinte: Quando você sabe que a exclusão do correções de código a bugs e você , em seguida, se perguntam se a escrever um teste, você já fez TDD errado. Depois de começar a trabalhar no bug, você deve primeiro escrever o teste que garante a presença do bug com falha. Somente depois você corrige o bug real - que pode exigir a remoção do código ou não - e faz o teste passar. A pergunta que você está fazendo nem se coloca dessa maneira.

— Frank
fonte

+1, mas posso imaginar a seguinte situação: o código removido continha alguma funcionalidade absurda que alguém adicionou que não entendeu o domínio do problema corretamente. Agora, durante uma revisão de código, outro desenvolvedor vê que toda a parte é realmente absurda e o código será removido. Ter muitos testes para esse comportamento sem sentido pode inchar seu conjunto de testes.

— Doc Brown

Claramente, a funcionalidade removida manipulou algumas entradas / saídas incorretamente. Claramente, alguém no futuro pode entender mal o problema da mesma maneira. Se você tem medo de inchar a suíte de testes, não acho que o TDD seja para você. O que é o inchaço do traje de teste?

— Dorus

@DocBrown: Se eles estão fazendo TDD, deve haver algum teste que exija essa funcionalidade absurda; caso contrário, eles não teriam permissão para escrever esse código em primeiro lugar! Lembre-se, você só pode escrever a quantidade mínima absoluta de código para obter a aprovação no teste. Se não houver esse teste, o código nunca deveria ter sido escrito em primeiro lugar e pode ser excluído. Se não é um teste que as forças que o comportamento absurdo, então esse teste deve ser removido, e agora estamos no mesmo caso que eu descrevi antes: o teste é ido, exclua o código.

— Jörg W Mittag

Nos dois casos, você nunca adiciona nenhum teste ao conjunto de testes e, no segundo caso, até remove um. No entanto, se o teste realmente fizer sentido, bem, a funcionalidade não era tão absurda, afinal.

— Jörg W Mittag