restrições de teste de unidade compreensão e ajudantes de sintaxe NUnit

Question

Eu e um colega estão começando um novo projeto e tentar tirar o máximo proveito de TDD. Ainda estamos tentando descobrir todos os conceitos em torno de teste de unidade e são, até agora, baseando-as principalmente em outros exemplos.

O meu colega recentemente posta em causa a ponto dos ajudantes de sintaxe NUnit e estou lutando para explicar seu benefício (desde que eu realmente não entendo isso sozinho não seja o meu instinto diz que eles são bons!). Aqui está um exemplo afirmação:

Assert.That(product.IsValid(), Is.False);

Para mim, isso faz todo o sentido, nós estamos dizendo que espera que o valor de product.IsValid() ser false. O meu colega, por outro lado que nos preferem simplesmente escrever:

Assert.That(!product.IsValid());

Ele diz-lhe isso faz mais sentido e ele pode lê-lo mais fácil.

Até agora, a única coisa que podemos concordar é que é provável que você obter uma saída mais útil quando o teste está a falhar a partir do antigo, mas eu acho que deve haver uma explicação melhor. Eu olhei algumas informações sobre os ajudantes de sintaxe ( http://nunit.com/blogs/? p = 44 ) e eles fazem sentido, mas eu não entendo completamente o conceito de outras restrições do que 'sentir' a direita.

Gostaria de saber se alguém poderia explicar por que usamos o conceito de restrições, e por que eles melhoram os exemplos de teste de unidade acima?

Graças.

Answer 1

Eu acho que é principalmente a ver com o puro Inglês leitura da declaração.

O primeiro lê

Assert que o produto é válido é false

O segundo lê

Assert que não produto é válido

Eu pessoalmente acho o primeiro mais fácil de processo. Eu acho que é tudo uma questão de preferência realmente. Alguns dos métodos de extensão lá fora são interessantes no entanto, que permitem que você faça você afirmações como esta:

product.IsValid().IsFalse();

Answer 2

Eu posso ver a sua versão ser melhor do que seus colegas. No entanto, eu ainda estaria pelo menos tão confortável com:

Assert.IsFalse(product.IsValid());

Se você pode me convencer de que a sintaxe Assert.That tem um benefício objectiva sobre o acima, eu estaria muito interessado :) Pode muito bem apenas a força do hábito, mas posso muito facilmente ler o "Que tipo de afirmação que estamos fazer? Agora o que estamos afirmando que se trata?" estilo.

Answer 3

É tudo açúcar. Internamente eles são convertidos em restrições.

De Testes Unitários Pragmático, pg 37:

"NUnit 2.4 introduziu um novo estilo de afirmações que são um pouco menos processual e permitem uma mais orientada a objeto subjacente implementação. ... Por exemplo:

Assert.That(actual, Is.EqualTo(expected));

converte em:

Assert.That(actual, new EqualConstraint(expected));"

Usando restrições também permite que você para herdar de restrição e criar seu próprio constrangimento personalizado (s), mantendo uma sintaxe consistente.

Answer 4

Eu não gosto Assert.That, especificamente o fato de que seu cenário mais comum (comparação de dois objetos igualdade) é mensurável pior do que o 'sintaxe clássica' Assert.AreEqual ().

Por outro lado, eu super amo as extensões MSpec NUnit. Eu recomendo que você vê-los (ou olhar para as extensões SpecUnit, ou extensões NBehave, ou N Behave extensões Spec * Unidade, eu acho que eles são todos iguais).