Come facilitare il TDD con MSTest / VS2008

Question

Ho letto più e più volte che TDD/test prima è più difficile con MSTest che con altri framework di test come nUnit, MBUnit, ecc...Quali sono alcune soluzioni alternative manuali suggerite e/o parti di terze parti che suggerisci quando MSTest è l'unica opzione a causa della politica dell'infrastruttura?Mi chiedo principalmente VS 2008 Team Suite, ma suppongo che anche i suggerimenti per VS 2008 Pro successivi sarebbero adatti poiché alcune funzionalità MSTest sono ora incluse anche in quelle versioni.

Answer 1

MSTest non è certamente efficiente o estensibile come alcuni framework open source, ma è realizzabile.Poiché la domanda riguarda come semplificare la vita con MSTest e non alternative, ecco i miei suggerimenti MSTest.

• Scorciatoie.Come ha detto Haacked, prenditi qualche secondo per imparare le scorciatoie.
• Contesto attuale.Poiché MSTest è molto lento, esegui i test solo nel contesto corrente quando puoi.(CTRL+R, CTRL+T).Se il cursore si trova in un metodo di test, verrà eseguito solo il metodo.Se il cursore si trova all'esterno di un metodo, ma in una classe di test, verrà eseguito solo il test.E con lo spazio dei nomi, ecc. Ecc
• Test e organizzazione efficienti.E' lentissimo.Rendi le cose nel miglior modo possibile scrivendo test efficienti.Sposta i test lenti in altre classi o progetti di test in modo da poter eseguire i test veloci più frequentemente.
• Test con WCF.Se stai testando i servizi, assicurati di eseguire il DEBUG dei test anziché l'ESECUZIONE dei test in modo che Visual Studio possa attivare i server Web di sviluppo ASP.NET.Dopo che questi sono terminati, puoi tornare a RUN, ma può essere più semplice eseguire sempre il DEBUG in modo da non doverci pensare.
• File di configurazione.Modifica la configurazione di esecuzione del test per spostare i file .config nella cartella di esecuzione del test.
• Integrazione con Source Safe.Devi essere consapevole che MSTest odia SourceSafe e il sentimento è reciproco.Poiché MSTest desidera mettere i file di test sotto il controllo del codice sorgente e aggiungerli alla soluzione, deve controllare la soluzione ogni volta che si eseguono test.Quindi SourceSafe deve essere eseguito in modalità multi-check-out per evitare di uccidere i tuoi colleghi sviluppatori.
• Ignora la lanugine Con MSTest ottieni una dozzina di finestre e visualizzazioni diverse.Esecuzioni di test, Visualizzazione test, Elenchi test...sono tutti poco utili.Attieniti ai risultati dei test e sarai molto più felice.
• Attenersi a "Test unitari".Quando aggiungi un nuovo test, puoi aggiungere un test ordinato, un test unitario o eseguire una procedura guidata.Attenersi a semplici test unitari.

Answer 2

Se non hai altra scelta che utilizzare MSTest, impara le scorciatoie da tastiera.Ti renderanno la vita un po' più semplice.

Test nel contesto attuale: CTRL+R, T
Tutti i test in soluzione: CTRL+R, UN

Test di debug nel contesto attuale: CTRL+R, CTRL+T
Eseguire il debug di tutti i test nella soluzione: CTRL+R, CTRL+UN

Answer 3

Sono curioso qui.Quello che non capisco è che le persone inizino a confrontare tutti gli strumenti Open Source disponibili con MSTest e inizino a criticarlo.Commentando quanto sia ingombrante, poco intuitivo, ecc.IMHO, è perché è fondamentalmente diverso dai framework xUnit.È ottimizzato per l'esecuzione parallela.

Anche il problema di avere ClassInitialze e Cleanup statici e di avere TestContext univoco per ciascuno dei test, tutto a causa dei concetti di programmazione parallela di prossima generazione - almeno per i programmatori aziendali Windows in linguaggi MS.

Ho avuto la sfortuna di lavorare in un progetto con decine di migliaia di unit test.Prima occupavano praticamente la maggior parte del tempo di costruzione!Con MSTest, lo riduciamo a tempistiche molto gestibili.

Answer 4

Il mio collega Mike Hadlow ha riassunto abbastanza bene il motivo per cui detestiamo assolutamente MSTest Qui.

È riuscito a rimuoverlo dal suo progetto, ma attualmente sto lavorando a un progetto più ampio con più politica coinvolta, quindi lo stiamo ancora utilizzando.

Il risultato è che chiunque abbia implementato MSTest non capisce TDD.Mi dispiace sembrare un attaccabrighe di M$, non lo sono davvero.Ma mi dà fastidio dover sopportare uno strumento molto scadente.

Answer 5

Non ho riscontrato problemi seri con MSTest.Di cosa stai parlando, nello specifico?Stiamo, infatti, passando da NUnit a MSTest.Non conosco le nostre ragioni, però.

Answer 6

Ci sono molti file di configurazione con mstest, il che lo rende meno conduttivo.
Un altro motivo per cui ho scelto mbunit è la funzionalità di "rollback" di mbunit.Ciò ti consente di ripristinare tutte le operazioni del database eseguite in questo test, in modo da poter effettivamente eseguire test del circuito completo e non preoccuparti che lo stagno venga contaminato dopo il test.
Inoltre mancanza di funzionalità RowTest in mstest.

Suggerisco semplicemente di eseguire mbunit come dipendenza all'interno del processo di compilazione, è abbastanza semplice spostarlo semplicemente con il cestino e fare riferimento, non è richiesta alcuna installazione.

Answer 7

• MSTest ha "alto attrito":Ottenere una sceneggiatura di build con Naant e Mbunit rispetto a MSTest e MSBuild.Nessun confronto.
• MSTEST è lento mbunit e nunit è nella mia esperienza più veloce (Gallio può aiutare qui)
• MSTEST aggiunge un sacco di cose di cui non ho bisogno come file di configurazione cablata ecc.
• MSTest non ha il set di funzionalità di altri framework di test del sistema operativo.controlla xUnit e MbUnit

È semplicemente troppo difficile da usare e ci sono molte opzioni migliori.

Answer 8

come accennato, è necessario installare l'IDE completo per poter utilizzare MSTest su un'altra macchina, il che è un po' schifoso.Suppongo che ciò sia dovuto al fatto che vogliono assicurarsi che i test unitari funzionino solo negli studi visivi di fascia alta e che tu non sia in grado di eseguirli in qualsiasi altro modo.

Inoltre, MSTest è piuttosto lento, questo perché tra ogni test ricostruisce l'intero contesto per ogni test, questo garantisce che un test precedente - fallito o altrimenti non influenzi il test corrente, ma rallenti le cose.puoi tuttavia utilizzare il flag /noisolation, che eseguirà tutti i test all'interno del processo MSTest, che è più veloce.Per accelerare nell'IDE:Nell'ide VS puoi andare su Strumenti-Opzioni quindi selezionare Strumenti di test.Seleziona la voce secondaria denominata Esecuzione del test e nella finestra di dialogo a destra assicurati che la casella di controllo denominata "Mantieni il motore di esecuzione del test in esecuzione tra le esecuzioni del test" sia selezionata.

Answer 9

Per rispondere a una domanda non a punta, la mia risposta sarebbe "probabilmente la NUNIT rimane fuori dal tuo viso".

Disclaimer:Non ho alcuna esperienza reale con la versione MS di xUnit, tuttavia sento problemi come "Devi installare l'idea gigantesca solo per eseguire i test su una macchina separata" - che è un no-no completo.A parte questo, MS ha questo modo di distorcere la strada giusta per un principiante tramite una sorta di campanello/fischio IDE che va contro l'intera idea.Come se la generazione di test dalle lezioni fosse una cosa che ricordo di circa un anno fa..questo sconfigge l'intero punto di prova di guida - il tuo design dovrebbe emergere da piccoli passi di RGR:scrivere un test per renderlo passa-refactoring.Se usi quello strumento, ti deruba dell'intera esperienza.

Mi fermo con il mio sermone..Ora :)

Answer 10

Ho sviluppato TDD utilizzando NUnit per diversi anni e utilizzo MSTest da circa 4 mesi a causa di un cambio di ruolo.

Non penso che MSTest impedisca a qualcuno di fare TDD.Hai ancora tutte le cose fondamentali di cui hai bisogno per TDD come asserzioni di base e framework di mocking (io uso Rhino Mocks).

MSTest si integra strettamente con Visual Studio, il componente migliore di questa integrazione è lo strumento Code Coverage integrato.

Ma ci sono una serie di ragioni convincenti non per utilizzare MSTest.Le due maggiori deviazioni secondo me sono:

1. La mancanza di opzioni di assert (rispetto a NUnit)
2. Il test runner lento (lento rispetto a NUnit)

Ciò significa che la scrittura delle asserzioni richiede più codice in combinazione con un test runner lento significa che l'intero processo è più lento di NUnit.Le opzioni open source hanno anche molto più supporto nella comunità.

Se utilizzi TFS per CI, dovrai eseguire alcuni passaggi/hack per fare in modo che NUnit pubblichi i risultati dei test.Eseguire test su TFS con MSTest a confronto è molto semplice e diretto.Se non tocchi TFS allora andrei NUnit fino in fondo, è semplicemente più carino.