ExceptionAsserts e il debug del progetto C # in VS

Question

Abbiamo utilizzato NUnit & VisualStudio di scrivere codice C # .NET per un po '. Eccezioni test è stato fatto nello stile di

vecchia sintassi:

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

}

Ora NUnit ha rilasciato la versione 2.5.2 che ha introdotto Assert.Throws( Type expectedExceptionType, TestDelegate code ); Questo fa eccezione la prova di un bel po 'più flessibile. I nostri test di eccezione appare così:

nuova sintassi:

[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");
}

Il nostro problema è che se Assert.Throws viene utilizzato Visual Studio verrà tirar fuori una finestra che mostra un'eccezione non gestita quando NUnit (o console o GUI runner) è utilizzato per eseguire il debug del programma.

per chiarire questo: abbiamo impostato il progetto VS contenente i test di unità per eseguire NUnit-x86.exe durante il debug. (Vedere le proprietà del progetto, scheda debug, avviare l'azione è impostata per eseguire NUnit-x86.exe)

Questa ferma NUnit di continuare i test. E 'possibile continuare il test di debug / unità premendo F5, ma questa non è una soluzione praticabile.

C'è un modo per evitare questo? Mettere un blocco try ... catch intorno alle Assert.Throws non fa nulla dal momento che l'eccezione accade nel codice delegato.

Spero che qualcuno possa far luce su questo.

Answer 1

Il problema in sé appare perché molto probabilmente si ha l'opzione Attiva Just My Code acceso (Strumenti> Opzioni> Debugging-> Generale-> Attiva Just My Code).

"Quando questa funzione è abilitata, i display Debugger e passi in codice utente (" Il mio Codice ") solo, ignorando il codice di sistema e altro codice che è ottimizzato o non ha simboli di debug" (vedi " Generale, Debug, finestra di dialogo Opzioni ")

Normalmente si dispone di una versione di nunit.framework.dll che non ha un file nunit.framework.pdb corrispondente.

Quindi ci sono 2 opzioni:

1. Disattiva "Just My Code" caratteristica

2. fonti di download di NUnit (da http://www.nunit.org /index.php?p=download ), costruirli in modalità debug, mettere tutti nunit.framework. * (dll, PDB, xml) nella lib o altra directory nella soluzione di riferimento e che nunit.framework.dll nel progetto di test.

Spero che questo aiuti.

Answer 2

Lo stesso problema anche mi ha infastidito per un bel po 'di tempo, ho fatto alcuni test e ha trovato il seguente:

Se una libreria (NUnit in questo caso) viene compilato con informazioni di debug impostato su 'none', allora se costruire simile a quella riportata di seguito viene eseguito withing la libreria e il codice del delegato genera un'eccezione, quindi VS ferma lamentarsi eccezione non gestita dal codice utente.

Code Library:

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

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

    return caughtException;
}

Codice cliente:

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

Impostazione informazioni di debug di un progetto di libreria a qualsiasi altra opzione diversa da 'none' risolve il problema cioè debugger non si ferma più su tali eccezioni Kinda "non gestite". L'ho provato con NUnit e la mia libreria arrotolato a mano con il codice di cui sopra (preso un frammento dal NUnit di metodo genera). Suppongo che sia una caratteristica o una "caratteristica" di VS.

E ci lascia con non così tante opzioni:

1. Filtro eccezione come precedentemente suggerito

2. Riconversione nunit.framework.dll per uso locale, al fine di evitare le soste fastidiosi

Altre opzioni potrebbero essere quello di contattare sia i team MS o NUnit o entrambi e chiedere loro di investigare / chiarire questione e compilare NUnit con livello minimo di informazioni di debug respectevily.

Modifica:

Trovato uno un'opzione più.

3. Nel mio caso deselezionando 'Sopprimere l'ottimizzazione JIT il carico del modulo' fa anche il trucco, anche se le librerie compilate senza informazioni di debug. Tuttavia funziona solo quando il progetto viene eseguito in configurazione di rilascio.

Answer 3

Penso che si sta essere accecati dalla asserzione NUnit. Si potrebbe ottenere la stessa cosa con una semplice try / catch.

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

Ora, si dispone di tutto il necessario. Non si riesce se l'eccezione non viene gettato e il tuo codice di regolare in grado di gestire le eccezioni come previsto.

Answer 4

Potrebbe essere realizzabile disabilitando l'eccezione. Aprire Debug / menù Eccezioni e ricerca per il tuo eccezione.