Devo continuar registrando uma falha?

Question

Estou trabalhando em um conjunto de testes de regressão automatizados para um aplicativo que mantenho.Ao desenvolver o teste de regressão automatizado, encontrei um comportamento que quase certamente é um bug.Então, por enquanto, modifiquei o teste de regressão automatizado para não registrar uma falha - quero dizer, ele está permitindo deliberadamente que esse mau comportamento passe.

Portanto, estou interessado nas opiniões de outras pessoas neste site.Obviamente, adicionarei um bug ao nosso rastreamento de defeitos para garantir que esse comportamento de erro seja corrigido.Mas há alguma razão convincente (de qualquer maneira) para alterar o teste de regressão para indicar falha constantemente ou deixar o teste de regressão quebrado e não falhar até que possamos corrigir o comportamento defeituoso?Penso nisso como um 6 de uma dúzia e meia de outro tipo de pergunta, mas pergunto aqui porque pensei que outros poderiam ver isso de forma diferente.

---

@Paul Tomblin,

Só para deixar claro: nunca pensei em remover o teste;Eu estava simplesmente pensando em modificar a condição de aprovação/reprovação para permitir a falha sem que ela aparecesse na minha cara toda vez que executo o teste.

Estou um pouco preocupado com as falhas repetidas de causas conhecidas que acabam sendo tratadas como avisos em C++.Conheço desenvolvedores que veem avisos em seu código C++ e simplesmente os ignoram porque pensam que são apenas ruídos inúteis.Receio que deixar uma falha conhecida no conjunto de regressão possa fazer com que as pessoas comecem a ignorar outras falhas, possivelmente mais importantes.

Aliás, para que não seja mal interpretado, considero os avisos em C++ uma ajuda importante na elaboração de código forte, mas a julgar por outros desenvolvedores de C++ que conheci, acho que estou em minoria.

Answer 1

Eu diria "inferno, sim!".O simples fato é: está falhando?Sim!Então deve ser registrado.Você está comprometendo seus testes ao permitir a aprovação de um teste que falhou.

Uma coisa que me preocuparia pessoalmente é que se eu fizesse isso e fosse para baixo de um ônibus, o "patch" poderia não ser removido, o que significa que mesmo após uma "correção de bug" o bug ainda poderia permanecer.

Deixe-o como está, atualize as notas do seu projeto, talvez até diminua a gravidade (se possível), mas certamente não quebre o que está verificando se há coisas quebradas;)

Answer 2

Se você parar de testá-lo, como saberá quando ele será consertado e, mais importante, como saberá se ele quebrará novamente?Sou contra retirar o teste, porque é provável que você se esqueça de adicioná-lo novamente.

Answer 3

Adicionamos um recurso de 'soneca' aos nossos testes de unidade.Isso permitiu que um teste fosse anotado com um atributo que basicamente dizia ‘ignorar falhas por X semanas a partir desta data’.Os desenvolvedores poderiam anotar um teste que sabiam que não seria corrigido por um tempo com isso, mas não era necessária nenhuma intervenção no futuro para reativá-lo manualmente, o teste simplesmente voltaria ao conjunto de testes no horário designado.

Answer 4

Deve continuar sendo um fracasso se não estiver fazendo o que era esperado.

Caso contrário, é muito fácil ignorar.Mantenha as coisas simples – funciona ou não.Falha ou sucesso :)

-Kevin Fairchild

Answer 5

Embora eu concorde com a maior parte do que Paul disse, o outro lado do argumento seria que os testes de regressão, estritamente falando, deveriam testar mudanças no comportamento do programa, e não apenas qualquer bug antigo.Eles deveriam especificamente avisar quando você quebrou algo que costumava funcionar.

Acho que isso se resume a outros tipos de testes executados neste aplicativo.Se você tiver algum tipo de sistema de teste unitário, talvez esse seja um local mais apropriado para este teste, ao invés do teste de regressão (pelo menos até que o bug seja corrigido).Porém, se os testes de regressão forem seus únicos testes, eu provavelmente deixaria o teste como está.

Answer 6

Embora seja melhor que os testes falhem quando há bugs, essa geralmente é uma escolha impraticável.Ao adicionar teste pela primeira vez a uma área, é particularmente fácil ficar atolado nos bugs descobertos e, portanto, não completar o objetivo principal.Além disso, testes com falha prolongada tornam-se muito barulhentos e cada vez mais fáceis de ignorar.

Escrever testes com falha faz parte da correção de bugs e só é realmente importante quando a correção desses bugs é importante.Isso deve ser determinado pelas suas prioridades atuais de produto e qualidade.Se acontecer de você produzir testes como efeito colateral de algum outro esforço, isso é bom, mas não deve desviá-lo de suas prioridades reais.

Eu recomendaria fazer quaisquer bugs descobertos enquanto melhorava os testes em avisos e arquivava bugs contra eles.É uma abordagem abrangente que o ajudará na tarefa atual e, ao mesmo tempo, usará o que aprender.Os testes podem então ser facilmente transformados em falhas reais quando os bugs estão programados para correção.

Ao contrário de outros entrevistados, acho que as falhas são tão fáceis de ignorar quanto os avisos, e o custo de treinar sua equipe para ignorar as falhas é alto demais para permitir que isso aconteça.Se você produzir testes com falha como parte desse esforço, terá destruído a utilidade do seu conjunto de testes de regressão quando a tarefa o estava melhorando.

Answer 7

Ter um teste reprovado é meio irritante.Há uma diferença entre código quebrado e código inacabado, e se o teste deve ser resolvido imediatamente depende da circunstância que esse teste com falha expõe.

Se estiver quebrado, você deve consertá-lo mais cedo ou mais tarde.Se estiver inacabado, resolva-o quando tiver tempo.

Em ambos os casos, é claro que você pode conviver com ele se comportando mal (por enquanto), portanto, desde que o problema seja registrado, é melhor não deixá-lo importuná-lo até que tenha tempo de corrigi-lo.