Você está realmente perguntando, "os testes de unidade ajudaram aqui?", ou você está perguntando, "algum tipo de teste poderia ter ajudado aqui?".
A forma mais óbvia de testar que teria ajudado, é uma afirmação de pré-condição no próprio código, que um identificador de ramificação consiste apenas em dígitos (supondo que essa é a suposição usada pelo codificador ao escrever o código). / p>
Isso poderia ter falhado em algum tipo de teste de integração e, assim que os novos IDs de ramificação alfanuméricos forem introduzidos, a asserção será ativada. Mas isso não é um teste de unidade.
Como alternativa, pode haver um teste de integração do procedimento que gera o relatório da SEC. Esse teste garante que todo identificador de ramificação real relate suas transações (e, portanto, requer entrada no mundo real, uma lista de todos os identificadores de ramificação em uso). Então, isso não é um teste de unidade.
Não consigo ver nenhuma definição ou documentação das interfaces envolvidas, mas pode ser que os testes de unidade não possam ter detectado o erro porque a unidade não estava com defeito . Se a unidade tiver permissão para assumir que os identificadores de ramificação consistem apenas em dígitos, e os desenvolvedores nunca tomaram uma decisão sobre o que o código deve fazer no caso contrário, eles não devem escrever um teste unitário para impor um comportamento específico no caso de identificadores não digitalizados porque o teste rejeitaria uma implementação válida hipotética da unidade que manipulava identificadores de ramificação alfanuméricos corretamente, e geralmente não se deseja gravar um teste de unidade que impeça futuras implementações e extensões válidas. Ou talvez um documento escrito há 40 anos implicitamente definido (por meio de um intervalo lexicográfico em EBCDIC bruto, em vez de uma regra de agrupamento mais humana) que 10B é um identificador de teste porque, de fato, fica entre 089 e 100. Mas então 15 anos atrás, alguém decidiu usá-lo como um identificador real, então a "falha" não está na unidade que implementa corretamente a definição original: ela está no processo que não percebeu que 10B é definido como um identificador de teste e, portanto, não deve ser atribuído a um ramo. O mesmo aconteceria em ASCII se você definisse 089 - 100 como um intervalo de teste e, em seguida, introduzisse um identificador 10 $ ou 1.0. Acontece que em EBCDIC os dígitos vêm depois das letras.
Um teste unitário (ou, possivelmente, um teste funcional) que concebivelmente pode ter salvo o dia, é um teste da unidade que gera ou valida novos identificadores de ramificação. Esse teste afirmaria que os identificadores devem conter apenas dígitos e seriam escritos para permitir que os usuários dos identificadores de ramificação assumam o mesmo. Ou talvez exista uma unidade em algum lugar que importe identificadores de ramificação reais, mas nunca veja os de teste, e que possa ser testada em unidade para garantir que ele rejeite todos os identificadores de teste (se identificadores são apenas três caracteres, podemos enumerá-los e comparar o comportamento de o validador ao do filtro de teste para garantir que eles correspondam, o que lida com a objeção usual aos testes spot). Então, quando alguém mudou as regras, o teste de unidade teria falhado, uma vez que contradiz o comportamento recém-exigido.
Como o teste estava lá por um bom motivo, o ponto em que você precisa removê-lo devido a requisitos de negócios alterados se torna uma oportunidade para alguém receber o trabalho ", encontre todos os lugares no código que dependem do comportamento queremos mudar ". Claro que isso é difícil e, portanto, não confiável, de modo algum garantiria salvar o dia. Mas se você capturar suas suposições nos testes das unidades que você está assumindo propriedades, então você se deu uma chance e então o esforço não é totalmente desperdiçado.
Concordo, claro, que se a unidade não tivesse sido definida em primeiro lugar com uma entrada de "formato engraçado", então não haveria nada para testar. Divisões de namespace complicadas podem ser difíceis de serem testadas corretamente porque a dificuldade não está em implementar sua definição engraçada, mas sim em garantir que todos entendam e respeitem sua definição engraçada. Isso não é uma propriedade local de uma unidade de código. Além disso, alterar alguns tipos de dados de "uma cadeia de dígitos" para "uma cadeia de alfanuméricos" é semelhante a fazer um programa baseado em ASCII manipular Unicode: não será simples se seu código estiver strongmente acoplado à definição original e o tipo de dados é fundamental para o que o programa faz, então ele é strongmente acoplado.
it’s a bit disturbing to think it’s largely wasted effort
Se os testes de sua unidade falharem (enquanto você estiver refatorando, por exemplo) e, ao fazer isso, fornecer informações úteis (a alteração está errada, por exemplo), o esforço não será desperdiçado. O que eles não fazem é testar se o seu sistema funciona. Então, se você está escrevendo testes de unidade ao invés de ter testes funcionais e de integração, então você pode estar usando seu tempo abaixo do ideal.