Devo interromper intencionalmente a compilação quando um bug é encontrado na produção?

Nossa estratégia é:

Faça check-in em um teste com falha, mas anote-o com @Ignore("fails because of Bug #1234") .

Dessa forma, o teste está lá, mas a compilação não quebra.

É claro que você nota o teste ignorado no banco de dados de bugs, então o @Ignore é removido assim que o teste é corrigido. Isso também serve como uma verificação fácil para a correção do bug.

O ponto de quebrar a compilação em testes com falha não é de alguma forma colocar a equipe sob pressão - é para alertá-los para um problema. Uma vez que o problema é identificado e arquivado no banco de dados do bug, não há sentido em executar o teste para cada compilação - você sabe que ele falhará.

Claro, o bug ainda deve ser corrigido. Mas agendar a correção é uma decisão de negócios e, portanto, não é realmente uma preocupação do desenvolvedor ... Para mim, quando um bug é arquivado no banco de dados de bug, não é mais meu problema, até que o cliente / proprietário do produto me diga que quer .

Why would you want to allow a build to succeed with known defects?

Porque às vezes você tem restrições de tempo. Ou o bug é tão pequeno que não vale a pena atrasar o envio do produto por alguns dias necessários para testar a unidade e consertá-lo.

Além disso, qual é o objetivo de quebrar a compilação intencionalmente toda vez que você encontrar um bug? Se você achou, conserte (ou atribua à pessoa que vai consertar), sem perturbar toda a sua equipe. Se você quiser se lembrar de consertar um bug, então você precisa marcá-lo como muito importante em seu sistema de rastreamento de bugs.

Existem testes para garantir que você não (re) introduza problemas. A lista de testes com falha não é um substituto para um sistema de rastreamento de bugs. Existe alguma validade no POV de que os testes em falha não são apenas indicação de bugs, eles também são uma indicação de falha no processo de desenvolvimento (de descuido a dependência mal identificada).

"Interromper a compilação" significa para evitar que uma compilação seja concluída com êxito . Um teste falho não faz isso. É uma indicação de que a construção tem defeitos conhecidos, o que é exatamente correto.

A maioria dos servidores de desenvolvimento rastreia o status dos testes ao longo do tempo e atribuirá uma classificação diferente a um teste que está falhando desde que foi adicionado a uma regressão (teste que costumava ser passado e não faz mais) e também detecta a revisão em que a regressão ocorreu.

Eu diria que o teste de falha deve ser adicionado, mas não explicitamente como "um teste de falha".

Como a @BenVoigt aponta em sua sua resposta , um teste que falhou não necessariamente "quebra a compilação". " Eu acho que a terminologia pode variar de equipe para equipe, mas o código ainda compila e o produto ainda pode ser enviado com um teste de falha.

O que você deve se perguntar nesta situação é,

What are the tests meant to accomplish?

Se os testes estiverem lá apenas para fazer com que todos se sintam bem com o código, adicionar um teste com falha apenas para que todos se sintam mal com o código não parece ser produtivo. Mas então, quão produtivos são os testes em primeiro lugar?

Minha afirmação é que os testes devem ser um reflexo dos requisitos de negócios . Portanto, se um "bug" for encontrado indicando que um requisito não foi atendido corretamente, então é também uma indicação de que os testes não refletem adequadamente ou totalmente os requisitos do negócio.

Esse é o bug a ser corrigido primeiro. Você não está "adicionando um teste com falha". Você está corrigindo os testes para refletir com mais precisão os requisitos de negócios. Se o código falhar nos testes, isso é bom. Isso significa que os testes estão fazendo o trabalho deles.

A prioridade de consertar o código deve ser determinada pela empresa. Mas até que os testes sejam corrigidos, essa prioridade pode realmente ser determinada? O negócio deve estar armado com o conhecimento de exatamente o que está falhando, como está falhando e por que está falhando para tomar suas decisões com prioridade. Os testes devem indicar isso.

Ter testes que não passam totalmente não é uma coisa ruim. Cria um grande artefato de problemas conhecidos a serem priorizados e tratados de acordo. Ter testes que não são totalmente testados, no entanto, é um problema. Isso questiona o valor dos testes em si.

Para dizer isso de outra maneira ... A compilação já está quebrada. Tudo o que você está decidindo é se deve ou não chamar a atenção para esse fato.

Em nossa equipe de automação de testes, nós verificamos os testes com falha, desde que eles falhem devido a um defeito no produto, em vez de um defeito no teste. Dessa forma, temos provas para o time de desenvolvimento que eles quebraram. Quebrar a compilação é altamente desaprovado, mas isso não é o mesmo que verificar os testes perfeitamente compiláveis, mas que falham.

Escrever um teste que você sabe que irá falhar até que o erro seja corrigido é uma boa ideia, é a base do TDD.

Quebrar a construção é uma má ideia. Por quê? Porque significa que nada pode seguir em frente até que seja consertado. Bloqueia essencialmente todos os outros aspectos do desenvolvimento.

Exemplo 1
E se o seu aplicativo for grande, com muitos componentes? E se esses componentes forem trabalhados por outras equipes com seu próprio ciclo de lançamento? Resistente! Eles têm que esperar pela correção do seu erro!

Exemplo 2
E se o primeiro bug for difícil de consertar e você encontrar um bug outro com uma prioridade mais alta? Você também quebra a compilação para o segundo bug? Agora você não pode construir até que ambos sejam corrigidos. Você criou uma dependência artificial.

Não há razão lógica para a falha de um teste parar uma compilação. Essa é uma decisão que a equipe de desenvolvimento precisa tomar (talvez com discussões gerenciais) avaliando os prós e contras de liberar uma compilação com bugs conhecidos. Isso é muito comum no desenvolvimento de software, praticamente todos os principais softwares são lançados com pelo menos alguns problemas conhecidos.

Depende do papel que os testes devem desempenhar e como seus resultados devem afetar o sistema / processo de compilação adotado. Meu entendimento de quebrar a compilação é o mesmo que o de Ben e, ao mesmo tempo, não devemos verificar intencionalmente o código que interrompe os testes existentes. Se esses testes vierem "mais tarde", pode ser "ok" ignorá-los apenas para torná-lo menos desnecessariamente perturbador para os outros, mas acho que essa prática de ignorar os testes fracassados (de modo que pareçam passar) é bastante perturbadora (especialmente para testes unitários), a menos que haja uma maneira de indicar tais testes como nem vermelhos nem verdes.

Depende do bug, é claro, mas, geralmente, se algo deu errado e não foi identificado durante o teste manual ou automatizado, isso significa que há uma lacuna na sua cobertura. Eu definitivamente encorajaria descobrir a causa raiz e colocar um caso de teste de unidade no topo do problema.

Se for um problema de produção planejado para um hot fix de um ramo de manutenção, também é necessário garantir que a correção funcione na linha principal e que um desenvolvedor não possa erroneamente eliminar a correção com um excesso de zelo mesclar resolução de conflitos.

Além disso, dependendo da política de lançamento, a presença de testes de unidade atualizados pode ajudar a confirmar que um desenvolvedor realmente corrigiu o problema, em vez de simplesmente alterá-lo [(o problema ou os testes?)], embora isso dependa tendo codificado os requisitos corretos nos novos testes unitários.

Um problema com a adição de um teste de conhecimento para a falha é que sua equipe pode ter o hábito de ignorar os testes com falha porque espera que a compilação falhe. Depende do seu sistema de compilação, mas se um teste falhar nem sempre significa "algo acabou de quebrar", então é fácil prestar menos atenção aos testes que falham.

Você não quer ajudar sua equipe a entrar nessa mentalidade.

Então eu concordo com o sleske que você deve adicione o teste, mas marque-o como 'ignorado' para o propósito da construção automática, até que o erro seja corrigido.

Embora eu ache que você deveria de alguma forma 'checar' o bug como teste, para que quando você corrigir isso não aconteça de novo, e de alguma forma o priorize, eu acho que é melhor não quebrar a compilação (/ Os testes). A razão é que os commits subsequentes serão quebrados por trás do teste quebrado. Então, ao verificar um teste quebrado para esse bug, você exige que toda a equipe defina seu trabalho para corrigir esse bug. Se isso não acontecer, você pode acabar quebrando commits que não são rastreáveis como tal.

Portanto, eu diria que é melhor enviá-lo como um teste pendente e tornar a sua equipa prioritária não ter testes pendentes.

Outra opção é verificar o teste com falha em uma ramificação separada no sistema de controle de origem. Dependendo de suas práticas, isso pode ser viável ou não. Às vezes, abrimos uma nova filial para trabalhos em andamento, como consertar um bug que não é trivial.