Compréhension des contraintes de test unitaire et des aides à la syntaxe NUnit

Question

Un collègue et moi-même commençons un nouveau projet et essayons de tirer pleinement parti du TDD. Nous sommes toujours en train de comprendre tous les concepts autour des tests unitaires et nous les basons principalement pour l'instant sur d'autres exemples.

Mon collègue a récemment remis en question l'intérêt des assistants à la syntaxe NUnit et j'ai du mal à expliquer leurs avantages (car je ne le comprends pas vraiment, à part que mon instinct dit qu'ils sont bons!). Voici un exemple d'assertion:

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

Pour moi, cela est tout à fait logique. Nous pensons que la valeur de product.IsValid () doit être false . Par ailleurs, mon collègue préférerait que nous écrivions simplement:

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

Il lui dit que cela a plus de sens et qu'il peut le lire plus facilement.

Jusqu'à présent, la seule chose sur laquelle nous pouvons nous mettre d'accord, c'est que vous obtiendrez probablement des résultats plus utiles lorsque le test échouera, mais je pense qu'il doit y avoir une meilleure explication. J'ai consulté des informations sur les aides à la syntaxe ( http://nunit.com/blogs/? p = 44 ) et ils ont un sens, mais je ne comprends pas tout à fait le concept de contraintes autres qu’ils se sentent bien.

Je me demande si quelqu'un pourrait expliquer pourquoi nous utilisons le concept de contraintes et pourquoi ils améliorent les exemples de tests unitaires ci-dessus?

Merci.

Answer 1

Je pense que c'est principalement lié à la lecture anglaise de la déclaration.

Les premières lectures

  

Affirmer que le produit est valide est faux

La seconde lit

  

Vérifiez que le produit n'est pas valide

Je trouve personnellement le premier plus facile à traiter. Je pense que c'est tout à fait à la préférence vraiment. Certaines méthodes d’extension sont intéressantes, mais vous permettent de faire des affirmations comme celle-ci:

product.IsValid().IsFalse();

Answer 2

Je vois que votre version est meilleure que vos collègues. Cependant, je serais toujours au moins aussi à l'aise avec:

Assert.IsFalse(product.IsValid());

Si vous pouvez me convaincre que la syntaxe de Assert.That présente un avantage objectif par rapport à ce qui précède, je serais très intéressé :) lisez le "Quel type d'affirmation faisons-nous? Maintenant, de quoi l’affirmons-nous? & Quot; style.

Answer 3

Tout est en sucre. En interne, ils sont convertis en contraintes.

Extrait des tests unitaires pragmatiques, p. 37:

"NUnit 2.4 a introduit un nouveau style d’assertions qui sont un peu moins procédurales et permettent une implémentation sous-jacente plus orientée objet. ... Par exemple:

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

Convertit en:

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

L'utilisation de contraintes vous permet également d'hériter de Constraint et de créer vos propres contraintes personnalisées tout en conservant une syntaxe cohérente.

Answer 4

Je n'aime pas Assert.That, en particulier le fait que son scénario le plus courant (comparer l'égalité de deux objets) est sensiblement pire que la syntaxe 'classique' Assert.AreEqual ().

D'autre part, j'aime beaucoup les extensions MSpec NUnit. Je vous recommande de les vérifier (ou de regarder les extensions SpecUnit, ou les extensions NBehave, ou les extensions N Behave Spec *, je pense qu'elles sont toutes identiques).