Ordine di controllo in cui ReSharper esegue i test unitari

Question

Esiste un modo per dire a ReSharper di eseguire un determinato gruppo di test in un progetto prima di altri? Voglio ancora l'esecuzione parallela e non ho bisogno di controllarlo per metodo, solo per classe. Il framework di test è MSTest se questo fa la differenza.

Il motivo per cui voglio farlo è che alcuni test funzionano a un livello basso e sono molto veloci, ma altri test funzionano a livelli più alti e sono molto più lenti. Voglio che i test rapidi vengano eseguiti per primi, perché se falliscono, so che c'è qualcosa di sbagliato e non ha senso continuare. Tuttavia, ReSharper al momento esegue prima i miei test lenti.

Modifica: I test non vengono eseguiti in ordine alfabetico per me (R # 7.1 su VS 2010). Ho un file sorgente per classe. I test all'interno di una classe sembrano essere eseguiti nell'ordine in cui i metodi appaiono nel codice sorgente, ma non riesco a capire come R # determina l'ordine delle classi di test. Questo è quello che cerco, poiché i test lenti e veloci sono in classi separate. Neanche questo è alfabetico, ma è coerente dall'inizio alla fine.

Modifica 2: OK, capito (vedi risposta).

Answer 1

Sembra che l'esecuzione del test sia in ordine alfabetico sotto forma di .... Quindi è possibile modificare il proprio nome/nomi di classe in modo che corrisponda all'ordine di prova. Ma immagino che non sia un'opzione per te.

Un'altra opzione è per aggiungere test a diverse sessioni di test nella finestra "Unità Test Sessions". Spostare i test rapidi alla Sessione n. 1 e rallentare i test sulla sessione n. 2. Quindi esegui solo una sessione di test di cui hai bisogno.

Non è un'opzione è quello di aggiungere TestCategory ai tuoi metodi di prova (cioè .: [TestCategory("Fast"), TestMethod] e [TestCategory("Slow"), TestMethod]) e raggruppare i test in Unit Test Sessions finestra Categorie. Questo ha l'effetto no per testare l'ordine.

Answer 2

Il motivo che voglio fare questo è che alcuni test lavorano a un basso livello e sono molto veloci, ma altri test funzionano a livelli più alti e sono molto più lenti .

vorrei suggerire un paio di metodi:

diviso i test in due progetti separati. Mettere le prove "veloci" in

YourProject.Test.Unit

ei test lenti a

YourProject.Test.Integration

test di integrazione sono di solito test che interagiscono con altri componenti (ad es. Una rete, di database, file system , ecc.) che potrebbe portare a cicli di test più lenti. Potrebbe essere che i test più lenti stiano accedendo a una risorsa esterna (non lo sappiamo).

Oppure utilizzare il suggerimento di @ thersch di utilizzare categorie per contrassegnare i test più lenti. Vorrei usare il metodo di categoria, i test sono in realtà tutti test unitari e quindi non avrebbe senso dividerli.

Answer 3

Questo sembra un po 'un trucco, ma ho scoperto che se rimuovo i file con i test lenti del progetto e li aggiungo nuovamente, vengono eseguiti per ultimi. Sembra quindi che R # tenga traccia dell'ordine in cui sono stati aggiunti i file sorgente contenenti classi di test e li esegue in tale ordine. (Modificare il file .csproj per riordinare i file non ha avuto alcun effetto, quindi non sembra utilizzarlo.)

Answer 4

Oppure, è possibile creare un test che orchestra le chiamate ad altri test nell'ordine desiderato - Quindi questo stesso test agisce come una "sessione".

[TestMethod] 
public void A_RunAllTests() 
{ 
    Test1(); 
    Test2(); 
    . 
    . 

} 

Answer 5

clic destro sul progetto unittest in Esplora soluzioni> Aggiungi> Prova ordinato ..

Non si può raggiungere questo ordinato di prova da ReSharper, ma sarà visualizzato nella VS test Explorer. Aggiungi i tuoi test ordinati a una specifica playlist di test VS e rimuovi i test coinvolti dalla sessione/sessione di Resharper.

Per risparmiare un sacco di file standard di solito utilizzo questa tecnica con il database aggiungi> ottieni> modifica> elimina test e dispone di un metodo di pulizia con l'attributo [ClassCleanup] per scorrere il database degli inserti di test nel caso uno dei test fallire.