Na minha opinião, vocês dois têm a vantagem e estão em "desvantagem" (sic).
A vantagem é que você tem um sistema com o qual se sente confortável e que funciona para você. Você está feliz por confirmar a validade do seu produto e provavelmente não encontraria valor comercial ao tentar alterar todos os seus testes por algo que usa uma estrutura diferente. Se você pode refatorar seu código e seus testes detectarem as alterações - ou, melhor ainda, se você puder modificar seus testes e seu código existente falhar nos testes até que seja refatorado, você terá todas as suas bases cobertas. Contudo...
Uma das vantagens de ter uma API de teste de unidade bem projetada é que há muito suporte nativo na maioria dos IDEs modernos. Isso não afetará os usuários avançados do VI e do emacs que zombam dos usuários do Visual Studio, mas para aqueles que usam um bom IDE, você pode depurar seus testes e executá-los dentro o próprio IDE. Isso é bom, no entanto, há uma vantagem ainda maior, dependendo da estrutura que você usa, e está no idioma usado para testar seu código.
Quando digo linguagem , não estou falando de uma linguagem de programação, mas de um conjunto rico de palavras envolvidas em uma sintaxe fluente que faz com que o código de teste seja lido como uma história. Em particular, me tornei um defensor do uso de estruturas de BDD . Minha API DotNet BDD favorita é StoryQ, mas existem vários outros com o mesmo objetivo básico, que é extrair um conceito de um documento de requisitos e escrevê-lo no código de maneira semelhante à maneira como ele é escrito na especificação. As APIs realmente boas, no entanto, vão ainda mais longe, interceptando todas as instruções individuais de um teste e indicando se essa instrução foi executada com êxito ou falhou. Isso é incrivelmente útil, pois você vê todo o teste executado sem retornar mais cedo, o que significa que seus esforços de depuração se tornam incrivelmente eficientes, pois você só precisa focar sua atenção nas partes do teste que falharam, sem precisar decodificar a chamada inteira seqüência. A outra coisa interessante é que a saída do teste mostra todas essas informações,
Como um exemplo do que estou falando, compare o seguinte:
Usando declarações:
Assert(variable_A == expected_value_1); // if this fails...
Assert(variable_B == expected_value_2); // ...this will not execute
Assert(variable_C == expected_value_3); // ...and nor will this!
Usando uma API BDD fluente:
(Imagine que os bits em itálico são basicamente indicadores de método)
WithScenario("Test Scenario")
.Given(*AConfiguration*) // each method
.When(*MyMethodToTestIsCalledWith*, variable_A, variable_B, variable_C) // in the
.Then(*ExpectVariableAEquals*, expected_value_1) // Scenario will
.And(*ExpectVariableBEquals*, expected_value_2) // indicate if it has
.And(*ExpectVariableCEquals*, expected_value_3) // passed or failed execution.
.Execute();
Agora que a sintaxe do BDD é mais longa e mais elaborada, e esses exemplos são terrivelmente inventados, no entanto, para situações de teste muito complexas nas quais muitas coisas estão mudando em um sistema como resultado de um determinado comportamento do sistema, a sintaxe do BDD oferece uma clara descrição sobre o que você está testando e como sua configuração de teste foi definida. Você pode mostrar esse código a um não programador e ele entenderá instantaneamente o que está acontecendo. Além disso, se "variable_A" falhar no teste em ambos os casos, o exemplo Asserts não será executado após a primeira afirmação até que você tenha corrigido o problema, enquanto a API BDD executará todos os métodos chamados na cadeia e indicará quais partes individuais da declaração estavam erradas.
Pessoalmente, acho que essa abordagem funciona muito melhor do que as estruturas xUnit mais tradicionais, no sentido de que a linguagem de teste é a mesma que seus clientes falarão de seus requisitos lógicos. Mesmo assim, eu consegui usar as estruturas xUnit de um estilo semelhante sem precisar inventar uma API de teste completa para apoiar meus esforços e, embora as declarações ainda efetivamente entrem em curto-circuito, elas são lidas com mais clareza. Por exemplo:
Usando Nunit :
[Test]
void TestMyMethod()
{
const int theExpectedValue = someValue;
GivenASetupToTestMyMethod();
var theActualValue = WhenIExecuteMyMethodToTest();
Assert.That(theActualValue, Is.EqualTo(theExpectedValue)); // nice, but it's not BDD
}
Se você decidir explorar o uso de uma API de teste de unidade, meu conselho é experimentar um grande número de APIs diferentes por um tempo e manter a mente aberta sobre sua abordagem. Embora eu defenda pessoalmente o BDD, suas necessidades comerciais podem exigir algo diferente para as circunstâncias da sua equipe. A chave, no entanto, é evitar adivinhar o sistema existente. Você sempre pode oferecer suporte aos testes existentes com alguns testes usando outra API, se necessário, mas eu certamente não recomendaria uma enorme reescrita de teste apenas para tornar tudo igual. Como o código legado fica fora de uso, você pode facilmente substituí-lo e seus testes por um novo código, além de testar usando uma API alternativa, e isso sem a necessidade de investir em um grande esforço que não trará necessariamente nenhum valor comercial real. Quanto ao uso de uma API de teste de unidade,