Ho intenzione di avviare un nuovo progetto al lavoro e voglio entrare in test unitari. Useremo VS 2008, C # e le cose ASP.NET MVC. Sto cercando di utilizzare NUnit o i progetti di test integrati di VS2008, 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 impostare questo progetto come una specie di "best practice" per i nostri sforzi di sviluppo.
Grazie per qualsiasi aiuto e suggerimenti !!
Risposte:
Daok ha nominato tutti i pro dei progetti di test VS2008, ecco i pro di NUnit.
Il framework di unit test non ha molta importanza, perché puoi convertire le classi di test con file di progetto separati e compilazione condizionale (come questa, VS-> NUnit):
#if! NUNIT utilizzando Microsoft.VisualStudio.TestTools.UnitTesting; #altro usando NUnit.Framework; utilizzando TestClass = NUnit.Framework.TestFixtureAttribute; utilizzando TestMethod = NUnit.Framework.TestAttribute; utilizzando TestInitialize = NUnit.Framework.SetUpAttribute; utilizzando TestCleanup = NUnit.Framework.TearDownAttribute; utilizzando TestContext = System.String; utilizzando DeploymentItem = NUnit.Framework.DescriptionAttribute; #finisci se
Il plug-in TestDriven.Net è carino e non molto costoso ... Con solo il semplice VS2008 devi trovare il test dalla tua classe di test o dalla tua lista di test. Con TestDriven.Net è possibile eseguire il test direttamente dalla classe che si sta testando. Dopotutto, il test unitario dovrebbe essere facile da mantenere e vicino allo sviluppatore.
Vantaggi / modifiche del framework di test unità integrato VS2008
Uso NUnit da 2 anni. Va tutto bene, ma devo dire che il sistema di unità in VS è piuttosto bello perché è all'interno della Gui e può più facilmente fare test per funzioni private senza doversi preoccupare. Inoltre, il Test unitario di VS ti consente di fare cover e altre cose che NUnit da sola non può fare.
Un leggero fastidio del framework di test di Visual Studio è che creerà molti file di test che tendono a ingombrare la directory del progetto, anche se non è un grosso problema.
Inoltre, se non si dispone di un plug-in come TestDriven.NET, non è possibile eseguire il debug dei test delle unità NUnit (o MbUnit, xUnit, ecc.) All'interno dell'ambiente Visual Studio, come è possibile con il framework di test Microsoft VS, integrato.
Leggermente fuori tema, ma se vai con NUnit posso consigliare di utilizzare ReSharper : aggiunge alcuni pulsanti all'interfaccia utente VS che rendono molto più semplice l'esecuzione e il debug dei test all'interno dell'IDE.
Questa recensione è leggermente obsoleta, ma lo spiega in modo più dettagliato:
XUnit è un'altra possibilità per un progetto greenfield. Ha forse una sintassi più intuitiva, ma non è realmente compatibile con gli altri framework.
Il mio obiettivo principale con i test unitari VS su NUnit è che la creazione del test VS tende a iniettare un sacco di codice generato per l'accesso di membri privati.
Alcuni potrebbero voler testare i loro metodi privati, altri no, questo è un argomento diverso.
La mia preoccupazione è quando scrivo unit test che dovrebbero essere estremamente controllati, quindi so esattamente cosa sto testando ed esattamente come lo sto testando. Se c'è un codice generato automaticamente sto perdendo parte di quella proprietà.
Ho fatto un 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 esegue i test reali sono le minuscole righe che puoi leggere qua e là. Un gran casino. In nUnit, il codice che esegue il test domina solo gli attributi, come dovrebbe fare.
Inoltre, in nUnit, devi solo fare clic sui test che vuoi eseguire (solo uno? Tutti i test che coprono una classe? Un assembly? La soluzione?). Un click. E la finestra è chiara e grande. Ottieni chiare luci verdi e rosse. Sai davvero cosa succede in un colpo solo.
In VSTS, l'elenco dei test è bloccato nella parte inferiore dello schermo, è piccolo e brutto. Devi guardare due volte per sapere cosa è successo. E non puoi eseguire un solo test (beh, non l'ho ancora scoperto!).
Ma potrei sbagliarmi, ovviamente - ho appena letto circa 21 post sul blog su "Come fare TDD semplice usando VSTS". Avrei dovuto leggere di più, hai ragione.
Per nUnit, ne ho letto uno. E stavo TDDing lo stesso giorno. Con divertimento.
A proposito, di solito adoro i prodotti Microsoft. Visual Studio è davvero lo strumento migliore che uno sviluppatore può acquistare, ma TDD e la gestione degli oggetti di lavoro in Visual Studio Team System fanno davvero schifo.
Ti auguro il meglio. Sylvain.
Ho ricevuto messaggi secondo cui "La struttura dei file NUnit è più ricca di VSTest" ... Naturalmente se preferisci la struttura dei file NUnit, puoi usare 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;
#endifO qualsiasi altra conversione ... :-) Questo utilizzo qui è solo un alias per il compilatore.
Per prima cosa voglio correggere un'istruzione errata: è possibile eseguire msTest al di fuori di Visual Studio utilizzando la riga di comando. Sebbene diversi strumenti di CI come TeamCity abbiano un supporto migliore per NUnit (probabilmente cambierebbe man mano che msTest diventa più popolare). Nel mio progetto attuale utilizziamo entrambi e l'unica grande differenza che abbiamo riscontrato è che mstest viene sempre eseguito come 32 bit mentre NUnit viene eseguito come test 32 bit o 64 bit, il che conta solo se il codice utilizza codice nativo che è 32/64 dipendente.
Ho iniziato con MSTest ma ho cambiato per un semplice motivo. MSTest non supporta l'ereditarietà dei metodi di test da altri assembly.
Odiavo 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 quello di cui ho bisogno. L'unica cosa che manca a NUnit è un componente aggiuntivo di Visual Studio che può visualizzare lo stato Rosso / Verde (come VSTS) di ogni test.
Se stai considerando MSTest o nUnit, ti consiglio di consultare mbUnit. Le mie ragioni sono
Inizialmente ho acquisito mbUnit a causa della sua funzionalità [RowTest ....] e non ho trovato un solo motivo per tornare indietro. Ho spostato tutte le mie suite di test attivi da nUnit e non ho mai guardato indietro. Da allora ho convertito due diversi team di sviluppo in vantaggi.
Per quanto ne so, al momento sono disponibili quattro framework per test unitari con .NET
NUnit è sempre stata in vantaggio ma il divario si è chiuso nell'ultimo anno circa. Preferisco ancora NUnit, soprattutto perché hanno aggiunto un'interfaccia fluida qualche tempo fa che rende i test molto leggibili.
Se hai appena iniziato a testare l'unità, probabilmente non fa molta differenza. Una volta che sarai pronto, sarai in una posizione migliore per giudicare quale struttura è la migliore per le tue esigenze.
Non mi piace il framework di test integrato VS perché ti costringe a creare un progetto separato anziché avere i tuoi test come parte del progetto che stai testando.
MSTest è essenzialmente NUnit leggermente rielaborato, con alcune nuove funzionalità (come l'impostazione dell'assemblaggio e lo smontaggio, non solo il dispositivo e il livello di test) e manca alcuni dei migliori bit (come la nuova sintassi del vincolo 2.4). NUnit è più maturo e offre maggiore supporto da parte di altri fornitori; e, naturalmente, dato che è sempre stato gratuito (mentre MSTest è entrato nella versione Professional del 2008, prima che fosse in SKU molto più costosi), la maggior parte dei progetti ALT.NET lo utilizza.
Detto questo, ci sono alcune aziende che sono incredibilmente riluttanti a usare qualcosa che non ha l'etichetta Microsoft su di esso, e in particolare il codice OSS. Pertanto, disporre di un quadro di prova ufficiale per gli Stati membri può essere la motivazione di cui tali aziende hanno bisogno per sottoporsi ai test; e siamo onesti, è il test che conta, non quale strumento usi (e usando il codice di Tuomas Hietanen sopra, puoi quasi rendere intercambiabile il tuo framework di test).
SetUpe TearDown: jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html
Con il rilascio in .NET 4.0 del sistema Code Contracts e la disponibilità di un controllo statico , sarebbe necessario scrivere teoricamente un numero inferiore di casi di test e uno strumento come Pex aiuterà a identificare tali casi. Collegandolo alla discussione in corso, se hai bisogno di fare di meno con i tuoi test unitari perché i tuoi contratti coprono la tua coda, allora perché non andare avanti e usare i pezzi incorporati poiché è una dipendenza in meno da gestire. In questi giorni, sono tutto sulla semplicità. :-)
Guarda anche:
Preferirei usare il piccolo framework di test di MS, ma per ora mi attengo a NUnit. I problemi con gli SM sono generalmente (per me)
Avvertenze - Se stessi testando un sito aspx, utilizzerei sicuramente MS - Se sviluppassi da solo, anche MS andrebbe bene - Se avessi abilità limitate e non potessi configurare NUnit :)
Trovo molto più semplice scrivere i miei test e accendere NUnitGUI o uno degli altri front-end (testDriven è di gran lunga molto costoso). Anche l'impostazione del debug con la versione da riga di comando è abbastanza semplice.