C'è qualcosa che posso fare in NUnit che non posso fare in MSTest?

Question

Questa domanda è stata posta sotto varie forme in diversi forum, ma, IMHO, non sono stato in grado di trovare un posto in cui sia stata data una risposta chiara, quindi ho intenzione di riformularlo e chiederglielo di nuovo.

Lavoro in un negozio Microsoft. Utilizziamo TFS e tutti i nostri sviluppatori hanno sottoscrizioni MSDN inclusa l'edizione Team Suite di VS. Quindi abbiamo accesso a MSTest.

Ho letto i vari confronti tra NUnit e MSTest e la comunità di sviluppatori sembra scegliere in modo schiacciante NUnit. Ma le ragioni fornite non sembrano mai schiaccianti o irresistibili, almeno per la nostra situazione. (NUnit viene aggiornato più spesso, NUnit è più veloce, NUnit non richiede TFS, ecc.)

Posso scegliere NUnit se scelgo, ma l'uso di software open source senza supporto formale dietro deve essere difeso . Ho bisogno di un motivo abbastanza convincente per farlo.

Quello che fondamentalmente devo rispondere per giustificare l'utilizzo di NUnit in preferenza per MSTest è questo: c'è qualcosa che posso fare in NUnit che non posso fare con sforzi analoghi in MSTest?

Answer 1

• NUnit contiene un attributo [TestCase] ​​che consente l'implementazione di test parametrizzati. Questo non esiste fuori dalla scatola in MSTest - può essere fatto attraverso l'estensibilità però.
• L'attributo ExpectedException di MsTest ha un bug in cui il messaggio previsto non viene mai realmente asserito anche se è errato - il test passerà.
• NUnit viene fornito con un'API Assert.Throws per consentire di verificare un'eccezione su una riga di codice specifica anziché sull'intero metodo. Esiste una funzionalità simile per MSTest (implementata dalla stessa persona che lo ha fatto per NUnit) ma non viene fornito con MSTest.
• NUnit contiene una versione fluente di Assert API pronta per l'uso. MSTest ha estensioni di terze parti che eseguono questa operazione, ma nessuna viene spedita con MSTest.
• NUnit consente alle classi astratte di essere proiettori di prova (quindi è possibile ereditare i dispositivi di prova). MsTest consente ciò ma limita le classi astratte a un singolo assembly.
• NUnit consente di classificare le classi non pubbliche (a partire dall'ultima versione)
• NUnit è stato creato SOLAMENTE per l'idea di test delle unità. MSTest è stato creato per i test e anche un po 'di test delle unità.
• NUnit contiene PNunit (test paralleli in esecuzione con NUnit). MSTest ha aggiunto questa capacità in Visual Studio 2010 che è configurabile via XML

Answer 2

NUnit dispone di richer assert API. L'API è particolarmente elegante (fluente, anche), per esempio

Assert.That(Is.Unique, myResults); // assert: myResults is a collection of unique items 

Se avete visto i Hamcrest estensioni per JUnit si riconosce questo stile.

Ha anche un crescente set of extensions, come test delle prestazioni e uno excellent VS plugin.

Answer 3

posso puntare a un paio di blog su frustrazioni con MSTest:

• MSBuild, NAnt, NUnit, MSTest, and frustration
• Clean build server with MSTest == FAIL

Per essere onesti, queste persone stanno cercando di istituire MSTest sulla non Server di compilazione TFS. Alcuni dei loro problemi non si applicano alla tua situazione.

Siamo principalmente un negozio Microsoft e utilizziamo TFS per il controllo del codice sorgente. Tuttavia, utilizziamo TeamCity per l'integrazione continua; ci piace, e si integra abbastanza bene con TFS. Non ho mai usato MSTest; abbiamo usato NUnit per anni e non ho visto alcun motivo per cambiare.

MSTest dovrebbe avere una stretta integrazione con Team Suite, che (dal momento che la tua azienda ha già pagato la tassa scandalosa per questo) è un punto a suo favore.

NUnit viene fornito con meno lock-in del fornitore e ha una ricca API. Come sottolineato da serg10, la sintassi Assert.That è particolarmente potente ed elegante.

Alla fine, è possibile scrivere buoni test di unità senza tutte le caratteristiche di fantasia. Alcuni di essi potrebbero addirittura intromettersi (che è la teoria dietro xUnit.net). Raccomanderei che il tuo team standardizzasse su un framework di test; evitare di avere qualche codice in MSTest e altri codici in NUnit.

Penso che scrivere buoni test sia più importante della scelta dei framework. Puoi leggere The Art of Unit Testing: with Examples in .NET, scrivere alcuni test e vedere se MSTest è adeguato alle esigenze della tua squadra.

MODIFICA: l'Appendice B di The Art of Unit Testing presenta alcuni commenti positivi sul quadro di verifica delle unità di Microsoft. Si parla di YUnit come esempio di quanto sia ingombrante estendere MSTest. Tuttavia, l'autore suggerisce MSTest per gli utenti del sistema Team a causa della stretta integrazione.

Answer 4

Ho lavorato al supporto di prima classe per MSTest in TestDriven.Net 3.0. Nelle versioni precedenti il ​​supporto MSTest era molto semplice (sembra che ci siano poche persone che usano MSTest).

A partire da TestDriven.Net 3.0 Beta 2, esiste un supporto abbastanza completo per tutti gli attributi relativi al test dell'unità di MSTest. Esiste anche il supporto per i test basati sui dati utilizzando l'attributo DataSource. I test verranno eseguiti anche a velocità prossime a NUnit!

Se si utilizza MSTest, sarei interessato a sentire se qualcuno dei test dell'unità fallisce quando viene eseguito utilizzando TestDriven.Net 3.0 Beta 2 (o successivo).

Si prega di provare sui vostri progetti MSTest e fatemi sapere come si ottiene: http://www.testdriven.net/download.aspx

NOTA, non supporta la DeploymentItem o HOSTTYPE attributi. È possibile utilizzare l'impostazione della voce di progetto 'Copia in uscita directory' anziché DeploymentItem.

Answer 5

È possibile modificare il codice in NUnit perché è open source. Non puoi farlo con MSTest.

Answer 6

Roy, un gruppo di informazioni non è aggiornato in particolare per quanto riguarda il 2010;

Nunit contiene un attributo [TestCase] ​​che consente l'implementazione di test parametrizzate. questo non esiste in MSTest

Questo può essere implementato usando unit test estensibilità nel 2010.

attributo ExpectedException di MSTest ha un bug in cui il messaggio atteso non è mai realmente affermato, anche se è sbagliato - il test passerà.

questo è ancora corrette

NUnit ha un API Assert.Throws per consentire test un'eccezione su una specifica linea di codice anziché l'intero metodo (si può facilmente implementare questo te stesso se)

Jim implented una versione di Assert.Throws per MSTest allo stesso tempo, come ha fatto l'o implementazione originale per NUnit, NUnit ha incluso nelle versioni successive, MSTest no, è ancora possibile utilizzarlo.

NUnit contiene una versione fluente di Assert API (come già detto - Assert.That ..)

ci sono molti di questi implementato da 3 parti per MSTest

NUnit è molto più veloce

commento

Sede di Jamie è riuscito a ottenere MSTest correre più veloce :-)

NUnit può eseguire test a 32 e 64 bit (MSTest li esegue solo in 32 bit IIRC)

Non nel 2010, il supporto a 64 bit è costruito in.

NUnit consente alle classi astratte di essere dispositivi di prova (in modo da poter ereditare i dispositivi di prova). MsTest no.

Questo funziona ma non tra gruppi che non limitano la sua utilità.

NUnit consente alle classi non pubbliche siano attrezzature di prova (a partire dalla versione più recente)

Ancora ci

NUnit è stato creato esclusivamente per l'idea di test unitario. MSTest è stato creato per i test e anche un po 'di test delle unità.

corretta, c'è un sacco di equivoco che MSTest è lo stesso di NUnit, ma MSTest è un quadro generalizzato.

NUnit contiene PNunit (esecuzione test paralleli con NUnit). MSTest non fa che aumentare questa capacità in vs 2010

corretta v'è un ambiente di configurazione XML che permette il controllo di grado di parallelismo.

Answer 7

Ho un bel modo tra MsTest e NUnit. È possibile utilizzare il framework MSTest per eseguire il test (attributo TestClass e attributo TestMethod per ciascun test) ma utilizzare l'API NUnit Assert.

solo fare questo:

using Microsoft.VisualStudio.TestTools.UnitTesting; 
using Assert = NUnit.Framework.Assert; 

Ora è possibile utilizzare Assert.That (..) e la relazione costruire e testare ancora hanno TFS automatizzato. il test può essere eseguito in VS, TestDriven.net o Resharper, non importa, il test fallirà o passerà correttamente, e l'output di errore sarà secondo il framework NUnit.

vedere qui: http://alsagile.com/archive/2010/03/09/stop-the-war-between-nunit-and-mstest-make-them.aspx

Answer 8

Vedi http://fluentassertions.codeplex.com. Si può fare cose come

"ABCDEFGHI".Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9); 

new[] { 1, 2, 3 }.Should().HaveCount(4, "because we thought we put three items in the 
collection")) 

dtoCollection.Should().Contain(dto => dto.Id != null); 

collection.Should().HaveCount(c => c >= 3); 

dto.ShouldHave().AllPropertiesBut(d => d.Id).EqualTo(customer); 

dt1.Should().BeWithin(TimeSpan.FromHours(50)).Before(dt2); 

Action action =() => recipe.AddIngredient("Milk", 100, Unit.Spoon); 
action 
    .ShouldThrow<RuleViolationException>() 
    .WithMessage("Cannot change the unit of an existing ingredient") 
    .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity 

Answer 9

1. Il MSTest test runner è non deterministico, che dovrebbe essere sufficiente per spaventare via da utilizzarlo. Non riesco a eseguire MSTest in modo coerente da TFS 2010 utilizzando il test runner integrato; si rompe con alcuni messaggi di errore diversi (e, in modo incoerente) tra le build del progetto e tra gli agenti di compilazione.
2. MSTest interruzioni a volte (non coerentemente) perché perdono memoria: le eccezioni di memoria ancora si verificano per noi, anche con la versione più recente di Visual Studio. La soluzione per questo problema è orribile.
3. Ho altri cavilli minori con MSTest, ed ho bloggato un mucchio di soluzioni alternative per l'utilizzo di MSTest in generale: http://www.pseale.com/blog/TFSAsYourBuildCIServerOnlyPositiveTakeaways1Of2.aspx

Ho trovato questa domanda come io ci sto passaggio a NUnit da MSTest perché non possiamo fidarci il risultato della nostra build CI è più dovuto a MSTest. Passare a NUnit ci permetterà (finalmente) di credere che un errore di compilazione di elementi di configurazione sia reale, non un altro problema MSTest. Questa è la vera risposta - solo con NUnit (o qualche altro corridore di test non MSTest) possiamo fidarci della nostra build CI.

Answer 10

È possibile eseguire facilmente i test NUnit su Linux con Mono e non penso che sia possibile farlo con i test per MSTest.

Answer 11

@Dave Hanna MS Test è disponibile immediatamente, quindi un componente in meno di cui preoccuparsi per l'implementazione e il mantenimento dell'aggiornamento. È inoltre integrato con Visual Studio e altri prodotti Microsoft di design.

La sintassi fluente è piacevole ma non è una differenza funzionale, quindi ignorerei.Per non parlare del fatto che si può avere lo stesso in MS Test usando una libreria di estensioni.

Prestazioni. Il 99% delle prestazioni del test è controllato dal sistema sottoposto a test, quindi anche una differenza di prestazioni del 100% tra due librerie comporterebbe una differenza generale ignorabile nelle prestazioni.

Open source vs. non open source: le possibilità di trarre vantaggio dall'utilizzo di una libreria open source sono minime. Le eccezioni si verificano quando le modifiche vengono importate nel trunk frequentemente o quando vi sono risorse sufficienti per mantenere aggiornato il ramo modificato.

Answer 12

Si prega di leggere attentamente la documentazione ExpectedExceptionAttribute, non è stato indicato da nessuna parte che il messaggio di eccezione venga verificato in modo che non sia un errore non affermato.

Il secondo parametro è il messaggio di asserzione che viene visualizzato quando non viene generato il tipo di eccezione prevista, non il messaggio di eccezione previsto. Cioè come il secondo parametro in Assert.IsTrue (condizione, messaggio).