Nunit: Le message d'exception est "TestDelegate" lors de l'utilisation de Throws.Nothing.After

Créé le 24 oct. 2016  ·  5Commentaires  ·  Source: nunit/nunit

Quelqu'un pourrait-il m'expliquer le comportement suivant ? (en supposant que ce ne soit pas un bug...). Lorsque vous utilisez le DelayedConstraint

Assert.That(() => {throw new Exception("hello");}, Throws.Nothing.After(100));
Les sorties:

Attendu : aucune exception à lever après un délai de 100 millisecondes
Mais était : <NUnit.Framework.TestDelegate>

Assert.That(() => {throw new Exception("hello");}, Throws.Nothing);
Les sorties:

Attendu : aucune exception à lever
Mais était : <System.Exception: hello
à ...

Je m'attends à ce que les deux produisent le deuxième message.

bug low

Commentaire le plus utile

Oui, cela a du sens. Nous devrons remplacer l'implémentation générale d'After pour ces contraintes particulières.

Tous les 5 commentaires

L'utilisation de After avec Throws n'a aucun sens mais si elle est autorisée, elle devrait donner un meilleur résultat.

Ma préférence serait de résoudre ce problème en rendant After indisponible sur cette contrainte au moment de la compilation. Si cela ne peut pas être fait, le message devrait indiquer que c'est une erreur de l'utiliser ici.

Puis-je vous demander pourquoi vous dites que cela n'a aucun sens ?

Parce que ce que nous essayons de faire dans notre test, c'est de nous assurer qu'après un certain temps, une méthode cesse de lancer (si vous êtes curieux de savoir pourquoi c'est parce que nous utilisons NSubstitute pour vérifier les appels - et jusqu'à ce que l'appel ait été vérifié, il lancera ).

Il _semblait_ Throws.Nothing.After serait approprié, et _semble_ fonctionner pour nous.

Donc, à chaque fois que la méthode est appelée, vous voudriez qu'elle réussisse si aucune exception n'est levée, mais continuez d'essayer si une est levée, n'échouant finalement qu'une fois le temps écoulé ? Ce serait cohérent avec la façon dont After fonctionne habituellement, bien que ce ne soit pas cohérent avec la façon dont nous gérons généralement les exceptions. :le sourire:

Et si vous utilisiez des jetés().Après ? Cela devrait-il être autorisé?

Oui, cela peut ne pas être cohérent avec la façon dont nous gérons généralement les exceptions, mais c'est ainsi que fonctionne l' API NSubstitute . Il existe des alternatives - nous pouvons effectuer notre propre vérification d'interrogation pour vérifier que l'appel est reçu, ou nous pouvons attendre autre chose avant de passer l'appel. Mais le cadre de contraintes retardées NUnit semble bien pour bon nombre de ces tests basés sur les threads/temps, d'où la raison pour laquelle j'essayais de l'utiliser.

TBH oui, je m'attendrais à ce que Throws.After fonctionne également. Tout ce que vous voudrez peut-être vérifier avec une contrainte évaluée immédiatement, je pense, est tout aussi logique que de travailler avec une contrainte retardée :-/

Oui, cela a du sens. Nous devrons remplacer l'implémentation générale d'After pour ces contraintes particulières.

Cette page vous a été utile?
0 / 5 - 0 notes