ExceptionAsserts et le débogage de votre projet C # VS

Question

Nous avons utilisé NUnit et VisualStudio pour écrire C # code .NET pour un certain temps maintenant. Exceptions Les tests ont été fait dans le style de

ancienne syntaxe:

[Test]
[ExpectException(typeof(ExceptionType))] 
public void TestExceptionType()
{

}

NUnit a publié la version 2.5.2 qui introduit Assert.Throws( Type expectedExceptionType, TestDelegate code ); Cela fait exception test beaucoup plus flexible. Nos tests d'exception ressemble maintenant à ceci:

nouvelle syntaxe:

[Test]
public void TestWithNullBufferArgument()
{
   ArgumentNullException ex = Assert.Throws<ArgumentNullException>(() => _testInstance.TestFunction(null));

   // now you can examine the exception and it's properties
   Assert.AreEqual(ex.Message, "Argument was null");
}

Notre problème est que si Assert.Throws est utilisé Visual Studio toussera une fenêtre montrant une exception non gérée lorsque NUnit (console ou le coureur GUI) est utilisé pour déboguer le programme.

pour clarifier ceci: nous avons mis le projet VS contenant les tests unitaires pour exécuter nunit-x86.exe lors du débogage. (Voir les propriétés du projet, onglet débogage, lancez l'action est configuré pour exécuter nunit-x86.exe)

Cela empêche NUnit de poursuivre les tests. Il est possible de poursuivre les tests de débogage / unité en appuyant sur F5, mais ce n'est pas une solution viable.

Y at-il moyen d'éviter cela? Mettre un bloc try ... catch autour de la Assert.Throws ne fait rien puisque l'exception se produit dans le code délégué.

J'espère que quelqu'un peut faire la lumière sur ce point.

Answer 1

Le problème lui-même apparaît parce que très probablement vous avez l'option Activer juste mon code activé (Outils-> Options-> Debugging-> Général-> Activer Just My Code).

« Lorsque cette fonction est activée, le débogueur affiche et pas dans le code utilisateur ( » Mon code « ) que, sans tenir compte du code du système et tout autre code qui est optimisé ou ne dispose pas de symboles de débogage » (voir « général, Debugging, boîte de dialogue options ")

Normalement, vous avez une version de nunit.framework.dll qui ne dispose pas d'un fichier nunit.framework.pdb correspondant.

Alors il y a 2 options:

1. Désactiver "Just My Code" fonction

2. Télécharger les sources de nunit (de http://www.nunit.org /index.php?p=download ), les construire en mode débogage, mettez tous nunit.framework. * (dll, pdb, xml) dans le répertoire lib ou tout autre répertoire dans votre solution et référence nunit.framework.dll dans votre projet de test.

Hope this helps.

Answer 2

Le même problème m'a ennuyé pendant un certain temps, je l'ai fait quelques tests et constaté ce qui suit:

Si une bibliothèque (nunit dans ce cas) est compilé avec les informations de déboguage « none », alors si construire semblable à celui ci-dessous est exécuté withing la bibliothèque et le code du délégué lance une exception, puis arrête VS se plaindre exception non gérée par le code d'utilisateur.

Code bibliothèque:

public static Exception Throws(TestDelegate code, string message)
{
    Exception caughtException = null;

    try
    {
        code();
    }
    catch (Exception ex)
    {
        caughtException = ex;
    }        

    return caughtException;
}

Code client:

private void btnTest_Click(object sender, EventArgs e)
{
  var ex = MyAssert.Throws(() => { throw new Exception(); }, "");    
}

Réglage informations de débogage d'un projet de bibliothèque à une autre option autre que « none » résout le problème à savoir débogueur ne s'arrête pas plus sur ces Kinda exceptions « non gérées ». Je l'ai testé avec nunit et ma propre bibliothèque roulées à la main avec le code ci-dessus (pris un extrait de méthode de nunit Lancers). Je suppose qu'il est une caractéristique ou une « fonction » de VS.

Il nous laisse pas beaucoup d'options:

1. exception du filtre comme précédemment suggéré

2. recompilation nunit.framework.dll pour une utilisation locale, afin d'éviter les arrêts gênants

D'autres options pourraient être à communiquer avec les équipes MS ou NUnit ou les deux et leur demander d'enquêter / clarifier problème et compiler NUnit avec un niveau minimal de mise au point d'information respectevily.

Edit:

trouvé une autre option.

3. Dans mon cas, décochant « Réprimer optimisation JIT de la charge du module » fait aussi l'affaire, même si les bibliothèques compilées sans informations de débogage. Cependant, il ne fonctionne que lorsque projet est exécuté dans la configuration de sortie.

Answer 3

Je pense que vous êtes aveuglé par l'affirmation NUnit. Vous pouvez obtenir la même chose avec un simple try / catch.

try
{
  _testInstance.TestFunction(null);
  Assert.Fail("The method should have thrown...");
}catch{}

Maintenant, vous avez tout ce dont vous avez besoin. Vous ne parvenez pas si l'exception est pas lancée et votre code régulier peut gérer les exceptions comme prévu.

Answer 4

pourrait-il être possible en désactivant l'exception. Ouvrir Debug / menu Exceptions et recherche de votre exception.