2015-10-14 9 views
9

Utilizzo i test Resharper 9.2 e NUnit 2.6.4 e ~ 120 unit. A volte, quando avvio i test, il ricercatore si arresta al test casuale e lo imposta su Aborted e salta gli altri. È molto scomodo perché ho eseguito manualmente il resto dei test. Ci sono dei modi per ottenere un motivo di aborto, alcuni registri di test di ricerca del resharper o qualcosa in NUnit per aiutare a risolvere il mio problema?Come posso ottenere il motivo dei test interrotti di Resharper?

Ho anche cercato di usare nativo corridore NUnit, ma a volte genera un'eccezione che non contiene alcuna informazione utile (qualche eccezione i servizi remoti che racconta nulla di utile)

Ho cercato di impostare "Run fino a 1 assemblee in parallelo "e" Usa AppDomain separato per ciascun assieme con test "ma non aiuta.

UPD

Ho riprodotto questo in modalità debug, il debug unit test appena spento e nella finestra di output che ho trovato:

The program '[4572] JetBrains.ReSharper.TaskRunner.CLR4.exe: Program Trace' has exited with code 0 (0x0). 
The program '[4572] JetBrains.ReSharper.TaskRunner.CLR4.exe: Managed (v4.0.30319)' has exited with code -1073741819 (0xc0000005) 'Access violation'. 

Sembra che il problema è la biblioteca di esterni non sicuri codice.

+1

Provare a eseguire il debug del codice nativo o semplicemente aggiungere la registrazione. –

risposta

1

Sembra che il programma di ricerca non abbia nulla a che fare in questo caso. Ho un errore di violazione di accesso e in questo caso il processo del tester verrà chiuso. Non esiste alcun modo in .net per elaborare questo errore perché non è a livello gestito. L'unica cosa è controllare nella finestra di output se il messaggio di errore è come: "Il programma" [4572] JetBrains.ReSharper.TaskRunner.CLR4.exe: gestito (v4.0.30319) 'è terminato con il codice -1073741819 (0xc0000005)' Accesso violazione "" quando i test vengono interrotti senza motivo. Se si ha accesso al codice nativo è possibile eseguire il debug.

Nel mio caso il problema era nell'uso improprio del metodo COM e del metodo Dispose(). L'ho risolto e ora tutto è a posto - nessun aborto "silenzioso".

+0

Dopo ore di ricerca su google, questa era la soluzione per me. Bravo! Ho eseguito il debug del test e ho visto un FatalExecutionEngineError nel codice nativo, che non presentava traccia dello stack, quindi mancava il messaggio di errore dei Resharpers. Ora so di cosa si tratta, posso aggiustarlo! –

1

Mi sono imbattuto in un caso in cui Resharper ha deciso di interrompere costantemente un test. Non ha chiamato in unmanaged o qualcosa di pazzo.

La risposta era che aveva una chiamata ricorsiva inavvertita risultante in un'eccezione di stackoverflow. Questo è stato evidente quando ho deciso di "eseguire il debug" invece di "eseguirli".

Quindi presumo che il take away generale sia che i test "abortiti" sono sintomatici che qualcosa è andato storto, ma l'errore non ha provocato un'eccezione generata dal codice stesso, ma dal CLR o qualcosa del genere.

+0

Il debug invece di eseguire è la chiave. È così semplice che voglio calciare me stesso. –

Problemi correlati