J'ai plusieurs personnes de ce modèle:
public static void ExpectException<_T> (Action action) where _T: Exception
{
try { action(); }
catch (_T) { return; }
Assert.Fail ("Expected " + _T);
}
4 Réponses :
YEP C'est joli tarif standard - beaucoup de nos tests font de même. Dans le même temps, vous devez vous demander si vous ne placez pas une valeur trop élevée sur la couverture du code si ces demi-branches pèsent tant que cela vaut la peine d'être effort.
Actuellement à une couverture d'horrible de 35%, cela n'ajoute donc pas beaucoup. C'est plus un problème de conception mineur (pouvant économiser quelques centaines de lignes de code de test).
Qu'est-ce que vous suggérez est valide. Outre votre problème de couverture de code, je dirais que cela vaut mieux que d'utiliser l'attribut Quelle serait une modification utile à ce que vous avez proposé Serait de retourner l'exception attrapée: Cela permettrait au code de test d'affirmer davantage l'exception si elle souhaitée (c.-à-d. Vérifier qu'un message particulier a été utilisé). < / p> Nunit (bien que cela ne semble pas que vous l'utilisez comme vous possédez un attendue car il montre explicitement quelle ligne du test devrait lancer l'exception. En utilisant attenduException signifie que une ligne de code de code dans le test peut lancer le type d'exception attendu et le test passera toujours. Si l'erreur provient d'un autre appel qui n'était pas censé lancer, il peut dissimuler le fait que le test devrait échouer car la ligne qui devrait être jetée n'est pas. TestMethod Attribut) a une construction intégrée similaire à ce que vous avez proposé:
+1. Bon produit. Cela m'a été amarré depuis un moment, mais je n'ai jamais eu le tour de la fixer.
@Adrianbanks L'espérance exception ne fonctionne pas comme prévu si le paramètre d'action jette une autre exception que l'exception attendue: lorsque j'exécute le testMethod "my_test", je viens de recevoir un message dire que La méthode de test soulevée et System.ArgumentException: Bonjour. Dans ce cas, il devrait indiquer "Invalidération attendueException".
Je propose une nouvelle version pour la méthode d'attente d'exception:
Je sais que c'est un ancien sujet, mais j'ai couru dans le même problème.
Finalement je me suis demandé: pourquoi dois-je connaître la couverture des tests? Je ne suis pas! - Règre donc, alors la couverture est plus propre. dans mon projet de test J'ai ajouté un codecoverage.RunSettings fichier et ceci est le contenu: après la sélection de ce paramètres de test fichier ma couverture de code est 100% ceci Voici aucun besoin de "pirater" le système de couverture de code de test de l'unité, juste pour atteindre 100%: -)
Merci pour cette idée! Je ne peux pas l'essayer moi-même, mais cela semble être une très bonne solution, si vous assurez simplement que les tests eux-mêmes sont corrects.