ExpectedException ne pas attraper l'exception, mais je peux l'attraper avec try catch

Question

Des idées sur celui-ci? J'essaie d'écrire un test unitaire qui va supprimer un élément et confirmer que l'élément n'est plus dans un référentiel en essayant de récupérer l'élément par son ID qui devrait lancer une exception DataAccessException. Cependant, le test continue d'échouer. J'ai ajouté un bloc try catch et bien sûr j'ai attrapé l'exception que je m'attendais. J'utilise VS Test Tools pour les tests unitaires.

[ExpectedException(typeof(DataAccessException))] 
    private static void NHibernateRepositoryBaseDeleteHelper<T, TKey>(T myItem, TKey myItemId) 
    { 
     MyTestRepository<T, TKey> myRepository = new MyTestRepository<T, TKey>(); 
     myRepository.Delete(myItem); 
     myRepository.CommitChanges(); 
     try 
     { 
      myRepository.GetById(myItemId, false); 
     } 
     catch (DataAccessException dae) 
     { 
      Assert.IsTrue(true); 
     } 
    } 

Answer 1

Vous devez ajouter l'attribut ExpectedException à la même méthode qui a l'attribut TestMethod. Le VS Unit Test Framework recherche uniquement un attribut ExpectedException au point d'entrée d'un test particulier.

[TestMethod] 
[ExpectedException(typeof(DataAccessException))] 
public void ATestMethod() { 
    ... 
    NHibernateRepositoryBaseDeleteHelper(itemValue, keyValue); 
} 

Answer 2

Vous supprimez d'abord votre méthode de suppression. J'aurais une méthode de suppression et une méthode de test séparées. Oui, vous testez la suppression, mais vous testez le comportement associé à la suppression. Il y a probablement des tests supplémentaires ici. Comme cela fait partie de ce qui semble être un test généré automatiquement, je ne voudrais pas ajouter au même objet de référentiel dans ce test, mais j'effectuerais mes tests dans leurs propres méthodes de test et utiliser la suppression dans le cadre de la mise en place pour la classe. Cela va certainement séparer le test de la suppression.

Espérons que cela aide.

Answer 3

Je vais ajouter à ce que Jared a dit en soulignant que l'attribut "ExpectedException" craint. Il n'y a aucun moyen d'affirmer que le message de l'exception est correct (le paramètre "message" ne fait pas ce que vous pensez qu'il fait) et vous ne pouvez pas vérifier plusieurs exceptions dans un test.

Une meilleure solution est de faire quelque chose comme ceci: http://geekswithblogs.net/sdorman/archive/2009/01/17/unit-testing-and-expected-exceptions.aspx

Cette classe vous permet de faire des choses propre comme ceci:

 
[TestMethod] 
public void TestAFewObviousExceptions() 
{ 
// some setup here 
    ExceptionAssert.Throws("Category 47 does not exist",() => 
       wallet.Categories.GetChildCategoryIds(47)); 
    ExceptionAssert.Throws("Id Flim is not valid",() => 
       wallet.Categories.IdFromName("Flim")); 
}