Progetti di test NUNit vs Visual Studio 2008 per test unitari?

Ho intenzione di avviare un nuovo progetto al lavoro e voglio entrare nei test unitari. Useremo VS 2008, C # e il materiale MVC ASP.NET. Sto cercando di utilizzare NUnit o i progetti di test integrati che VS2008 ha, ma sono aperto alla ricerca di altri suggerimenti. Un sistema è migliore dell’altro o forse più facile da usare / capire dell’altro? Sto cercando di rendere questo progetto impostato come una sorta di “best practice” per i nostri sforzi di sviluppo in futuro.

Grazie per qualsiasi aiuto e suggerimento !!

Daok ha nominato tutti i pro dei progetti di test VS2008, ecco i pro di NUnit.

  • NUnit ha una struttura beffarda.
  • NUnit può essere eseguito all’esterno dell’IDE, questo può essere utile se si desidera eseguire test su un server di build non MS come CC.Net
  • NUnit ha più versioni in uscita rispetto allo studio visivo. Non devi aspettare anni per una nuova versione E non devi installare una nuova versione dell’IDE per ottenere nuove funzionalità.
  • Ci sono estensioni sviluppate per NUnit come test di riga ecc.
  • I test di Visual Studio richiedono molto tempo per l’avvio per qualche motivo. Questo è meglio nel 2008, ma ancora troppo lento per i miei gusti. Eseguire rapidamente un test per vedere se non si è rotto qualcosa può richiedere troppo tempo. NUnit con qualcosa come Testdriven.Net per eseguire test dall’IDE è in realtà molto più veloce. soprattutto quando si eseguono test singoli.
    Accettando a Kjetil Klaussen ciò è causato dal test runner di Visual Studio, l’esecuzione dei test MSTest in TestDriven.Net rende le prestazioni MSTest paragonabili a quelle di NUnit.

Il framework di test delle unità non ha molta importanza, perché è ansible convertire le classi di test con file di progetto separati e compilazioni condizionali (come VS-> NUnit):

  #if! NUNIT
   utilizzando Microsoft.VisualStudio.TestTools.UnitTesting;
  #altro
   utilizzando NUnit.Framework;
   using TestClass = NUnit.Framework.TestFixtureAttribute;
   using TestMethod = NUnit.Framework.TestAttribute;
   using TestInitialize = NUnit.Framework.SetUpAttribute;
   using TestCleanup = NUnit.Framework.TearDownAttribute;
   using TestContext = System.String;
   using DeploymentItem = NUnit.Framework.DescriptionAttribute;
  #finisci se

Il plugin TestDriven.Net è bello e non molto costoso … Con solo VS2008 devi trovare il test dalla tua class di test o dalla tua lista di test. Con TestDriven.Net puoi eseguire il test direttamente dalla class che stai testando. Dopotutto, il test dell’unità dovrebbe essere facile da mantenere e vicino allo sviluppatore.

Vantaggi / cambiamenti del framework di test unità built-in VS2008

  1. La versione 2008 ora è disponibile in edizioni professionali (prima che richiedesse versioni costose di VS, questo è solo per i test delle unità degli sviluppatori.) Che lasciava molti sviluppatori con l’unica scelta di framework di test aperti / esterni.
  2. API integrata supportata dalla singola azienda.
  3. Utilizzare gli stessi strumenti per eseguire e creare test (è ansible eseguirli utilizzando la riga di comando anche MSTest)
  4. Design semplice (concesso senza framework Mock, ma questo è un ottimo punto di partenza per molti programmatori)
  5. Supporto a lungo termine concesso (ricordo ancora cosa è successo a nDoc, non voglio impegnarmi in un framework di test che potrebbe non essere supportato in 5 anni, ma considero ancora nUnit un ottimo framework).
  6. Se si utilizza il server di base team come back-end, è ansible creare elementi di lavoro o bug con i dati di test non riusciti in modo semplice.

Sto usando NUnit per 2 anni. Tutto va bene, ma devo dire che il sistema Unit in VS è piuttosto carino perché è all’interno del Gui e può più facilmente fare test per la funzione privata senza dover fare casino. Inoltre, il test unitario di VS ti permette di fare copertura e altre cose che NUnit da solo non può fare.

Un leggero fastidio del framework di test di Visual Studio è che creerà molti file di test run che tendono a ingombrare la directory del progetto, anche se questo non è un grosso problema.

Inoltre, se ti manca un plug-in come TestDriven.NET, non puoi eseguire il debug dei test di unità NUnit (o MbUnit, xUnit, ecc.) All’interno dell’ambiente di Visual Studio, come è ansible con il framework di testing Microsoft VS, che è integrato.

Un po ‘fuori tema, ma se si va con NUnit posso consigliare l’uso di ReSharper – aggiunge alcuni pulsanti all’interfaccia utente VS che semplificano l’esecuzione e il debug dei test dall’interno dell’IDE.

Questa recensione è leggermente obsoleta, ma lo spiega in modo più dettagliato:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

XUnit è un’altra possibilità per un progetto greenfield. Forse ha una syntax più intuitiva, ma non è realmente compatibile con gli altri framework.

http://www.codeplex.com/xunit

Il mio manzo principale con i test delle unità VS su NUnit è la creazione del test VS che tende a iniettare un po ‘di codice generato per l’accesso ai membri privati.

Alcuni potrebbero voler testare i loro metodi privati, altri no, è un argomento diverso.

La mia preoccupazione è quando scrivo test unitari che dovrebbero essere estremamente controllati, quindi so esattamente cosa sto testando e esattamente come lo sto testando. Se c’è codice generato automaticamente, sto perdendo parte di quella proprietà.

Ho fatto un po ‘di TDD usando entrambi e (forse sono un po’ stupido) nUnit sembra essere molto più veloce e più semplice da usare per me. E quando dico molto, intendo molto.

In MS Test, ci sono troppi attributi, ovunque: il codice che fa i veri test sono le piccole linee che puoi leggere qua e là. Un gran casino. In nUnit, il codice che esegue il test domina semplicemente gli attributi, come dovrebbe fare.

Inoltre, in nUnit, devi solo fare clic sui test che vuoi eseguire (solo uno? Tutti i test che riguardano una class? Un assembly? La soluzione?). Un click. E la finestra è chiara e grande. Ottieni chiare luci verdi e rosse. Sai davvero cosa succede in un’unica vista.

In VSTS, la lista dei test è bloccata nella parte inferiore dello schermo, è piccola e brutta. Devi guardare due volte per sapere cosa è successo. E non puoi eseguire solo un test (beh, non l’ho ancora scoperto!).

Ma potrei sbagliarmi, ovviamente – ho appena letto circa 21 post di blog su “Come fare semplice TDD usando VSTS”. Avrei dovuto leggere di più, hai ragione.

Per nUnit, ne ho letto uno. E io ero TDDing lo stesso giorno. Con divertimento.

A proposito, di solito amo i prodotti Microsoft. Visual Studio è davvero lo strumento migliore che uno sviluppatore può acquistare, ma la gestione TDD e Work Item in Visual Studio Team System fa davvero schifo.

Ti auguro il meglio. Sylvain.

Ho ricevuto messaggi che “la struttura del file NUnit è più ricca di VSTest” … Naturalmente se si preferisce la struttura del file NUnit, è ansible utilizzare questa soluzione in un altro modo, come questo (NUnit-> VS):

#if !MSTEST using NUnit.Framework; #else using Microsoft.VisualStudio.TestTools.UnitTesting; using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute; using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute; using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute; using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute; #endif 

O qualsiasi altra conversione … 🙂 Questo uso qui è solo alias del compilatore.

Per prima cosa voglio correggere un’affermazione sbagliata: puoi eseguire msTest all’esterno di visual studio usando la riga di comando. Sebbene diversi strumenti di configurazione come TeamCity offrano un supporto migliore per NUnit (probabilmente cambieranno con l’aumentare della popolarità di msTest). Nel mio progetto attuale usiamo entrambi e l’unica differenza grande che abbiamo trovato è che mstest viene sempre eseguito a 32 bit mentre NUnit viene eseguito come test a 32 o 64 bit, il che importa solo se il codice utilizza un codice nativo dipendente da 32/64.

Ho iniziato con MSTest ma sono passato per un semplice motivo. MSTest non supporta l’ereditarietà dei metodi di test da altri assembly.

Ho odiato l’idea di scrivere lo stesso test più volte. Soprattutto su un grande progetto in cui i metodi di test possono essere facilmente eseguiti in centinaia di test.

NUnit fa esattamente ciò di cui ho bisogno. L’unica cosa che manca con NUnit è un Addin di Visual Studio che può visualizzare lo stato Rosso / Verde (come VSTS) di ciascun test.

.NET Testing Framework Advice e pacchetti di test dell’unità .NET? .

Se stai considerando MSTest o nUnit, allora ti consiglio di guardare mbUnit. Le mie ragioni sono

  1. Compatibilità con TestDriven.Net. Niente di meglio che TestDriven.Net.ReRunWithDebugger sia associato a una combinazione di tastiere.
  2. La struttura di Gallio. Gallio è un runner di prova come nUnits. L’unica differenza è che non importa se hai scritto i tuoi test in nUnit, msTest, xUnit o mbUnit. Vanno tutti a correre.
  3. Compatibilità con nUnit. Tutte le funzionalità di nUnit sono supportate da mbUnit. Penso che tu non abbia nemmeno bisogno di cambiare i tuoi attributi (dovremo verificarlo), solo il tuo riferimento e le tue usanze.
  4. La raccolta afferma. mbUnit ha più casi Assert, inclusa la class CollectionAssert. Fondamentalmente non è più necessario scrivere i propri test per vedere se 2 collezioni sono uguali.
  5. Test combinatori Non sarebbe bello se potessi fornire due serie di dati e ottenere un test per tutte le combinazioni di dati. È in mbUnit.

Originariamente ho scelto mbUnit per la sua funzionalità [RowTest ….] e non ho trovato una sola ragione per tornare indietro. Ho spostato tutte le mie suite di test attive da nUnit e non mi sono mai voltato indietro. Da allora ho convertito due diversi team di sviluppo in benefici.

Per quanto ne so, in questi giorni sono disponibili quattro framework per il test delle unità con .NET

  • NUnit
  • MbUnit
  • MSTest
  • xUnit

NUnit è sempre stata davanti, ma il divario si è chiuso nell’ultimo anno circa. Preferisco ancora NUnit me stesso, soprattutto perché hanno aggiunto un’interfaccia fluente un po ‘indietro che rende i test molto leggibili.

Se hai appena iniziato con il test delle unità, probabilmente non fa molta differenza. Una volta che sei al passo, sarai in una posizione migliore per giudicare quale struttura è la migliore per le tue esigenze.

Non mi piace il framework di testing integrato VS perché ti costringe a creare un progetto separato invece di fare i test come parte del progetto che stai testando.

MSTest è essenzialmente NUnit leggermente rielaborato, con alcune nuove funzionalità (come l’assemblaggio e il teardown, non solo il fixture e il livello di test), e mancano alcuni dei migliori bit (come la nuova syntax del vincolo 2.4). NUnit è più maturo e c’è più supporto da parte di altri fornitori; e naturalmente dal momento che è sempre stato gratuito (considerando che MSTest è entrato nella versione Professional del 2008, prima era in SKU più costosi), la maggior parte dei progetti di ALT.NET lo usa.

Detto questo, ci sono alcune aziende che sono incredibilmente riluttanti a usare qualcosa che non ha l’etichetta Microsoft su di esso, e specialmente il codice OSS. Quindi avere una struttura ufficiale di test sulla MS può essere la motivazione che queste aziende hanno bisogno di testare; e siamo onesti, è il test che conta, non quale strumento usi (e usando il codice di Tuomas Hietanen sopra, puoi quasi rendere il tuo framework di test intercambiabile).

Con il rilascio in .NET 4.0 del sistema dei Contratti di codice e la disponibilità di un controllo statico , è necessario scrivere in teoria meno casi di test e uno strumento come Pex aiuterà a identificare tali casi. Riferendoti alla discussione, se hai bisogno di fare meno con i tuoi test unitari perché i tuoi contratti coprono la tua coda, allora perché non andare avanti e usare i pezzi integrati dato che è meno dipendente da gestire. In questi giorni, sono tutto sulla semplicità. 🙂

Guarda anche:

  • Microsoft Pex – Test unitario automatizzato
  • Generazione di test unitari con Pex utilizzando Visual Studio 2010 e C # 4.0

Preferirei usare la piccola struttura di test di MS, ma per ora mi sto attenendo a NUnit. I problemi con gli MS sono generalmente (per me)

  • File “test” condivisi (inutili) che devono essere mantenuti
  • Gli elenchi di test causano conflitti con più sviluppatori / VCS
  • Scarsa interfaccia utente integrata – configurazione confusa, selezione di test gravosa
  • Nessun buon corridore esterno

Avvertenze – Se dovessi provare un sito aspx, userei sicuramente MS – Se sviluppassi solo, anche MS andrebbe bene – Se avessi capacità limitate e non potessi configurare NUnit 🙂

Trovo molto più facile scrivere semplicemente i miei test e accendere NUnitGUI o uno degli altri front-end (testDriven è di gran lunga troppo costoso). Anche impostare il debugging con la versione a riga di comando è abbastanza semplice.