Esta pergunta contém vários conceitos errôneos da IMHO, mas o principal que eu gostaria de focar é que ela não diferencia entre agências locais de desenvolvimento, tronco, estágios ou agências de lançamento.
Em uma ramificação de desenvolvimento local, é provável que tenha alguns testes de unidade com falha a qualquer momento. No porta-malas, só é aceitável em algum grau, mas já é um strong indicador para corrigir as coisas o mais rápido possível. Observe que os testes de unidade com falha no tronco podem perturbar o restante da equipe, pois exigem que todos verifiquem se a última alteração dele não causou a falha.
Em uma ramificação de teste ou de liberação, os testes com falha são "alerta vermelho", mostrando que algo foi completamente errado com algum changeset, quando foi mesclado do tronco para o ramo de release.
I would even suggest that even releasing software with failing unit tests is not necessary bad.
Liberar software com alguns erros conhecidos abaixo de determinada gravidade não é necessariamente ruim. No entanto, essas falhas conhecidas não devem causar um teste de unidade com falha. Caso contrário, após cada teste de unidade, será necessário examinar os 20 testes de unidade com falha e verificar um por um se a falha foi aceitável ou não. Isso fica pesado, propenso a erros e descarta uma grande parte do aspecto de automação dos testes de unidade.
Se você realmente tiver testes para bugs conhecidos e aceitáveis, use o recurso de desabilitar / ignorar da ferramenta de testes de unidade (para que eles não sejam executados por padrão, apenas sob demanda). Além disso, adicione um tíquete de baixa prioridade ao rastreador de problemas, para que o problema não seja esquecido.