Embora existam maneiras de impedir que os testes de unidade sejam executados, qual é o valor de verificar os testes de unidade com falha?
Vou usar um exemplo simples: Case Sensitivity. O código atual faz distinção entre maiúsculas e minúsculas. Uma entrada válida para o método é "Cat" e retornaria uma enumeração de Animal.Cat. No entanto, a funcionalidade desejada do método não deve diferenciar maiúsculas de minúsculas. Portanto, se o método descrito fosse aprovado como "gato", ele poderia retornar algo como Animal.Null em vez de Animal.Cat e o teste de unidade falharia. Embora uma simples alteração de código faça com que isso funcione, um problema mais complexo pode levar semanas para ser corrigido, mas identificar o bug com um teste de unidade pode ser uma tarefa menos complexa.
O aplicativo atualmente em análise possui 4 anos de código que "funciona". No entanto, discussões recentes sobre testes de unidade encontraram falhas no código. Alguns precisam apenas de documentação de implementação explícita (por exemplo, com distinção entre maiúsculas e minúsculas) ou código que não executa o bug com base em como ele é chamado atualmente. Porém, testes de unidade podem ser criados executando cenários específicos que farão com que o erro seja visto e sejam entradas válidas.
Qual é o valor do check-in em testes de unidade que exercitam o bug até que alguém possa corrigir o código?
Este teste de unidade deve ser marcado com ignorar, prioridade, categoria etc., para determinar se uma compilação foi bem-sucedida com base nos testes executados? Eventualmente, o teste de unidade deve ser criado para executar o código assim que alguém o corrigir.
Por um lado, mostra que os erros identificados não foram corrigidos. Por outro lado, pode ser difícil encontrar centenas de testes de unidade com falha aparecendo nos logs e eliminar aqueles que devem falhar versus falhas devido a um check-in de código.