Come si esegue NUnit in modalità debug da Visual Studio?


120

Recentemente ho creato un framework di test per un po 'di C # su cui ho lavorato. Ho configurato NUnit e un nuovo progetto nel mio spazio di lavoro per testare il componente. Tutto funziona bene se carico i miei unit test da Nunit (v2.4), ma sono arrivato al punto in cui sarebbe davvero utile eseguire in modalità debug e impostare alcuni punti di interruzione.

Ho provato i suggerimenti di diverse guide che suggeriscono di modificare le proprietà 'Debug' del progetto di test:

Start external program: C:\Program Files\NUnit 2.4.8\bin\nunit-console.exe
Command line arguments: /assembly: <full-path-to-solution>\TestDSP\bin\Debug\TestDSP.dll

Sto usando la versione per console lì, ma ho provato anche a chiamare la GUI. Entrambi mi danno lo stesso errore quando provo ad avviare il debug:

Cannot start test project 'TestDSP' because the project does not contain any tests.

È perché normalmente carico \ DSP.nunit nella GUI di Nunit ed è lì che si svolgono i test?

Sto cominciando a pensare che il problema potrebbe essere che VS vuole eseguire il proprio framework di test ed è per questo che non riesce a trovare i test NUnit?

Modifica : per coloro che chiedono informazioni sui dispositivi di prova, uno dei miei file .cs nel progetto TestDSP ha più o meno questo:

namespace Some.TestNamespace
{
    // Testing framework includes
    using NUnit.Framework;

    [TestFixture]
    public class FirFilterTest
    {
        [Test]
        public void Test01_ConstructorTest()
        {
            ...some tests...
        }
    }
}

... Sono abbastanza nuovo di C # e del framework di test NUnit, quindi è del tutto possibile che mi sia perso alcune informazioni cruciali ;-)

Soluzione finale : il grosso problema era il progetto che avevo utilizzato. Se scegli Other Languages -> Visual C# -> Test -> Test Project... quando scegli il tipo di progetto, Visual Studio proverà a utilizzare il proprio framework di test per quanto posso dire. Dovresti invece scegliere un normale progetto di libreria di classi C # e quindi le istruzioni nella risposta selezionata funzioneranno.


La tua classe di dispositivi di prova mi sembra a posto, quindi deve essere qualcosa nel progetto come hai suggerito.
Patrick McDonald

2
Assomiglia a questa domanda: stackoverflow.com/questions/247900/… La risposta è la stessa ...
Patrick Desjardins

Risposte:


46

Uso la stessa tecnica che stai provando con Jon, senza il flag / assembly, ad es

Start External Program: C:\Program Files\NUnit 2.4.8\bin\nunit.exe

Command line arguments: "<path>\bin\Debug\Quotes.Domain.Tests.dll"

TestDSP.dll contiene tutti i tuoi TestFixtures?

Poiché il mio progetto di test non è il progetto di avvio nella soluzione, eseguo i miei test facendo clic con il pulsante destro del mouse sul progetto di test e scegliendo Debug -> Avvia nuova istanza


1
Ho provato quello che hai suggerito (rimuovendo / assembly) ma non fa differenza. Quando avvio una nuova istanza, viene generato l'errore. Penso che sia principalmente a che fare con il fatto che quando ho creato il progetto TestDSP l'ho creato dal modello di progetto di test di VisualStudio integrato, quindi sta cercando il framework di test sbagliato.
Jon Cage

3
Finalmente ha funzionato. Avevo ragione in quanto erano le opzioni del progetto a bloccarlo: ricreare il progetto di test utilizzando il modello di classe standard ha risolto il problema.
Jon Cage,

1
Aiuta se aggiungi anche /runai tuoi * argomenti della riga di comando che inizieranno automaticamente a eseguire i test ... Ho anche riassunto tutto (usando immagini) nel mio post sul blog .
Robert Koritnik

6
Nel caso in cui le persone non controllino il post del blog (molto utile) di Robert ( erraticdev.blogspot.com/2012/01/… ): per .NET 4.0 e versioni successive, credo che tu debba aggiungerlo anche a nunit.exe.config : <startup> <supportedRuntime version = "4.0" /> </startup>.
devuxer

3
Seguito: nelle versioni successive di NUnit (l'ultima versione ad oggi è v2.6.1), è necessario commentare <supportedRuntime version="v2.0.50727" />in nunit.exe.config.
devuxer

102

Quando ho bisogno di eseguire il debug dei miei test NUnit, mi collego semplicemente all'applicazione GUI di NUnit nunit-agent.exeutilizzando "Debug | Collega al processo" ed eseguo i test dalla GUI. Tutti i punti di interruzione nei miei test (o il codice che stanno testando) vengono raggiunti. Sto fraintendendo la tua domanda o funzionerà per te?


7
Per tua (e per altre) informazioni: Debug | Attach non è disponibile nelle edizioni Express di VS.
Richard

15
Tieni presente che devi selezionare "Abilita supporto Visual Studio" nella finestra di dialogo Impostazioni di NUnit -> Supporto IDE
Julio Garcia

8
Per .NET 4.0 e versioni successive, credo che si hanno anche per aggiungere questo ai nunit.exe.config: <startup> <supportedRuntime version="4.0" /> </startup>.
devuxer

1
Questa è una scorciatoia rapida per collegarsi al processo corretto (eseguito nella console di Gestione pacchetti): ($ dte.Debugger.LocalProcesses |? {$ _. Name.EndsWith ("nunit-agent.exe")}). Attach ()
bart

7
Cordiali saluti: è necessario collegare il debug al processo chiamato "nunit-agent.exe" e NON "nunit.exe". Altrimenti i tuoi breakpoint vengono ignorati e ti chiedi perché ...
Jenny O'Reilly

21

Rimuovi semplicemente la linea che sembra

<ProjectTypeGuids>
    {3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
</ProjectTypeGuids>

dal file di progetto. Questa riga fondamentalmente dice a VS.Net che si tratta di un progetto di test, quindi "Impossibile avviare il progetto di test". Per tua informazione, il primo Guid dice "è un test", il secondo dice "è C #". Per informazioni su queste guide: http://www.mztools.com/Articles/2008/MZ2008017.aspx


18

Oltre alla risposta fornita da @Justin, ecco alcuni dettagli in più per NUnit 2.6.

Utilizzando NUnit 2.6, connettersi a nunit.exe o nunit-console.exe e NON all'agente. La configurazione annotata da @Justin è leggermente diversa. Di seguito è riportato un esempio da nunit.exe.config (lo stesso per nunit-console.exe.config).

<startup useLegacyV2RuntimeActivationPolicy="true">
  <!-- Comment out the next line to force use of .NET 4.0 -->
  <supportedRuntime version="v2.0.50727" />  
  <supportedRuntime version="v4.0.30319" />
</startup>

Per il progetto di test .NET 4, per ottenere punti di interruzione da raggiungere, sarà necessario commentare o rimuovere la riga v2.0 come suggerisce il commento. Dopo averlo fatto, sono stato in grado di eseguire il debug del progetto di test .NET 4.0.


Ho avuto successo solo con la v2.0.50727linea durante il debug di assembly .NET 2 da VS2005 con nunit. (La v4linea ha impedito al debugger di VS 2005 di collegarsi.)
Martin Ba

17

Se stai usando NUnit 2.4 o più recente puoi inserire il seguente codice nella tua SetUpFixtureclasse. (Puoi farlo con le versioni precedenti, ma dovrai fare tutto l'equivalente di SetUpFixture, o copiarlo nel test stesso.)

[SetUpFixture]
public class SetupFixtureClass
{
    [SetUp]
    public void StartTesting()
    {
        System.Diagnostics.Debugger.Launch();
    }
}

Ciò che Debugger.Launch()fa è visualizzare la seguente finestra di dialogo quando si fa clic su Esegui in NUnit.

Finestra di dialogo debugger JIT

Quindi scegli la tua istanza in esecuzione di Visual Studio con il tuo progetto aperto (il secondo nel mio screenshot), quindi il debugger verrà allegato e tutti i punti di interruzione o le eccezioni verranno visualizzati in Visual Studio.


12

In Nunit 3.0.1 (sto usando VS2013), Apri dal menu principale> Test> Windows> Esplora test. Quindi in "Esplora test", fai clic con il pulsante destro del mouse sul test case, potresti vedere: inserisci qui la descrizione dell'immagine

Spero che questo ti aiuti.


2
Grazie per questa risposta. Molto più semplice di tutti gli altri.
dano

Sto usando NUnit 2.5.9 in VS 2015 e ha funzionato con un'estensione VS denominata "NUnit 2 Test Adapter". È possibile eseguire il test nella finestra Esplora test.
mggSoft

6

Installa TestDriven.NET , che è un plug-in per Visual Studio

Da lì puoi fare clic con il pulsante destro del mouse sull'assembly di unit test e fare clic su Esegui test per eseguire l'intera suite, fare clic con il pulsante destro del mouse su una classe TestFixture per eseguire solo i test in quella classe o fare clic con il pulsante destro del mouse su un metodo Test per eseguire solo quel metodo.

Hai anche la possibilità di testare con debugger, se hai bisogno di breakpoint nei tuoi test in modalità debug.


2
$ 170 è incredibilmente alto per uno strumento del genere. Riduzione dei prezzi, chiunque?
Ben Hardy

Si. Per quel tipo di denaro, preferirei investire in JetBrains Resharper che poi fornisce gratuitamente il Test Runner con l'integrazione di debug e un sacco di altre funzionalità di produttività.
Roman

Con Visual Studio 2012 puoi ottenere gratuitamente NUnit Test Runner con Nuget.
Jon Limjap

6

Prova NUnitit, un componente aggiuntivo di Visual Studio open source per il debug dei casi di test di NUnit

HomePage - http://nunitit.codeplex.com/


È abbastanza buono anche se non riesco a trovare un modo per dirgli di eseguire solo un singolo test (?)
Jon Cage,


3

Ora con le immagini:

  1. Esegui NUnit gui ( Scarica 2.6.2 da qui ) quindi vai aFile -> Open Project

inserisci qui la descrizione dell'immagine

  1. Seleziona il tuo test .dlldalla cartella bin ( C:\......\[SolutionFolder][ProjectFolder]\bin\Debug\xxxxTests.dll)

  2. Vai a Visual Studio Debug -> Attach to process(si aprirà la finestra Allega al processo)

  3. Dall'elenco scorrere verso il basso e selezionare, nunit-agent.exequindi fare clicAttach

inserisci qui la descrizione dell'immagine

  1. A questo punto i breakpoint nei test dovrebbero diventare rossi maturi (da vuoti).

  2. Fai clic Runsu Nunit Guie dovresti ottenere il tuo breakpoint hit ...

Spero che questo ti faccia risparmiare tempo.


2

Se riesci a far funzionare la console / o la GUI, ma i tuoi punti di interruzione non vengono raggiunti, potrebbe essere perché la tua app esegue un runtime .NET diverso da NUnit. Controlla se il tuo nunit-console.exe.config / nunit.exe.config ha il runtime specificato (le configurazioni risiedono nella stessa directory dell'exe nunit). Specifica il runtime utilizzando il nodo di avvio:

<configuration>
    <startup>
       <supportedRuntime version="4.0" />
    </startup>

2

Se il percorso del progetto contiene spazi, ad es. "Nuovo progetto" nel percorso <path>\bin\Debug\New Project\Quotes.Domain.Tests.dll racchiudere l'opzione di avvio -> Argomenti della riga di comando percorso del progetto tra virgolette doppie.

Ho passato molto tempo a capirlo.


1

Riguardo a ciò che ha detto il signor Patrick McDonald

Poiché il mio progetto di test non è il progetto di avvio nella soluzione, eseguo i miei test facendo clic con il pulsante destro del mouse sul progetto di test e scegliendo Debug -> Avvia nuova istanza

Ho provato a fare domanda per la mia libreria di classi di test ma ho ricevuto qualche errore riguardo al percorso, quindi ho provato a rimuovere gli "Argomenti della riga di comando" e fortunatamente ha funzionato bene e come previsto.


0

Sembra che tu stia cercando di utilizzare la libreria sbagliata. NUnit può essere avviato solo se la DLL che stai utilizzando contiene TestFixtures.

+1 su TestDriven.Net. Ho avuto la possibilità di usarlo diverse volte. È possibile scaricare la versione personale a scopo di valutazione secondo la licenza su http://testdriven.net/purchase_licenses.aspx .


Vedere la modifica recente: ho un dispositivo di prova anche se è del tutto possibile che non l'abbia impostato correttamente.
Jon Cage

0

Ho ricevuto lo stesso errore con MSTest. Ho scoperto che nella finestra Test Output , alcuni dei test avevano ID duplicati e non potevano essere caricati. Ho rimosso tutti i test duplicati e ora sono stato in grado di eseguire i test quando avvio il progetto.


0

Ora è disponibile anche un'estensione "Visual NUnit" che consentirà di eseguire i test da Visual Studio in modo molto simile agli handle del framework di test compilato. Controllalo nel gestore estensioni.


0

Apri Visual Studio ---> il tuo progetto ---> Seleziona 'Proprietà' ---> Seleziona 'Debug' -> Seleziona 'Avvia programma esterno' e imposta lì il percorso della tua NUnit (Es: Avvia programma esterno = C : \ Programmi \ NUnit 2.6.2 \ bin \ nunit.exe) ----> Salva

Dopo averlo impostato, fai clic su Debug


0

Per me la soluzione era adattare il file di configurazione di nunit. Per utilizzare nunit con 4.5-.Net framework e l'opzione di build x64, ho dovuto aggiungere una riga al tag di avvio (versione runtime supportata).

<startup useLegacyV2RuntimeActivationPolicy="true">
        <!-- Comment out the next line to force use of .NET 4.0 -->
        <supportedRuntime version="v4.0.30319" />
</startup>

Successivamente, potrei iniziare facendo clic con il pulsante destro del mouse su Testproject Debug -> Avvia nuova istanza. Prima, dovevo ricollegare manualmente il progetto al processo.

Le mie proprietà di debug erano C: \ Programmi (x86) \ NUnit 2.6.4 \ bin \ nunit.exe con argomento della posizione del .dll da testare.

Ulteriori informazioni: nunit per il test con .NET 4.0


-1

Vedi se questo aiuta .. Come aggiungere NUnit in Visual Studio

(RighteousRant) Anche se personalmente non mi piace questo approccio .. Se hai bisogno di un debugger mentre stai testando il tuo codice, è un "odore" in quanto non hai abbastanza fiducia / sai come funziona il tuo codice e hai bisogno del debugger per dirti questo. TDD dovrebbe liberarti dalla necessità di un debugger se fatto bene. Usa "Allega debugger a NUNit" solo in rari casi o quando stai cercando di leggere il codice di qualcun altro.


Ho provato i suggerimenti lì senza alcun risultato. Hai chiaramente un buon naso. So che il mio codice non funziona poiché l'output che ricevo per il primo blocco di implementazione sta ottenendo risposte completamente diverse al mio riferimento di test. Quindi ora sto cercando di approfondire per trovare la causa del problema. Preferisco farlo isolatamente al resto del programma (da qui la necessità di eseguire unit test in modalità debug). Per la cronaca, questo è un codice scritto da qualcun altro che è stato convertito dall'algoritmo di un'altra persona: - /
Jon Cage,

Quindi questo rientra nell'ultima clausola della mia ultima riga :) Strano che tu non riesca a farlo funzionare però .. peccato. Direi che basta allegare al processo (Alt + D + P) senza soffermarsi su di esso ..
Gishu

Non c'è odore qui: ho un test case che fallisce in determinati ambienti (viene restituito un risultato molto sbagliato) e ho bisogno di capire perché. Per fare ciò, voglio eseguire il debug e scoprire dove non funziona in questo ambiente in modo da poter correggere il codice e far passare il test ovunque. Sembra roba di tipo rosso / verde standard ...
BrainSlugs83

@ BrainSlugs83 - molto tempo da quando ho scritto questo. Sono (ancora) contrario al debug dei test come pratica di lavoro primaria. Casi limite: mi va bene il passaggio al debugger. Anche allora probabilmente inserirò prima gli stmts di registrazione .. Penso che derivi dal fatto che ho osservato troppe persone che utilizzano un ciclo Code-Crash-Debug-Adjust che viene semplificato al ciclo Code-Crash-Adjust con il debugger continuamente acceso.
Gishu
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.