2010-06-03 17 views
9

ho pensato ho capito come l'esecuzione di test parallelo di MbUnit ha funzionato, ma il comportamento che sto vedendo differisce sufficientemente molto dalla mia aspettativa che ho il sospetto mi manca qualcosa!esattamente come di MbUnit [parallelizzabile] e DegreeOfParallelism funziona?

Ho una serie di test dell'interfaccia utente che desidero per l'esecuzione simultanea. Tutti i test sono nello stesso assembly, suddivisi in tre diversi spazi dei nomi. Tutti i test sono completamente indipendenti l'uno dall'altro, quindi vorrei che tutti fossero idonei per l'esecuzione parallela.

A tal fine, ho messo il seguente nei AssemblyInfo.cs:

[assembly: DegreeOfParallelism(8)] 

[assembly: Parallelizable(TestScope.All)] 

La mia comprensione è che questa combinazione di attributi di assemblaggio dovrebbe causare tutti i test da considerare [Parallelizable], e che il test runner dovrebbe usare 8 thread durante l'esecuzione. I miei test individuali sono contrassegnati con l'attributo [Test] e nient'altro. Nessuno di questi è basato sui dati.

Tuttavia, ciò che in realtà vedo è nella maggior parte delle discussioni 5-6 in uso, il che significa che le mie corse di prova stanno prendendo più a lungo di quanto dovrebbero essere.

Mi manca qualcosa? Devo fare altro per garantire che tutti i miei 8 thread vengano utilizzati dal corridore?

N.B. Il comportamento è lo stesso indipendentemente da quale corridore io uso. La GUI, la riga di comando e i corridori TD.Net si comportano tutti come descritto sopra, portandomi ancora a pensare che mi sia sfuggito qualcosa.

MODIFICA: Come indicato nei commenti, eseguo v3.1 di MbUnit (aggiornamento 2 build 397). Il documentation suggerisce che l'attributo livello di assembly [parallelizable] è disponibile, ma fa anche riferimento sembrano V3.2 del quadro nonostante non essendo ancora disponibile.

EDIT 2: Per chiarire ulteriormente, la struttura del mio montaggio è la seguente:

assembly 
- namespace 
    - fixture 
     - tests (each carrying only the [Test] attribute) 
    - fixture 
     - tests (each carrying only the [Test] attribute) 
- namespace 
    - fixture 
     - tests (each carrying only the [Test] attribute) 
    - fixture 
     - tests (each carrying only the [Test] attribute) 
- namespace 
    - fixture 
     - tests (each carrying only the [Test] attribute) 
    - fixture 
     - tests (each carrying only the [Test] attribute) 

EDIT 3: OK, ora ho notato che se ho sempre e solo eseguito un apparecchio a contemporaneamente, il numero massimo di prove eseguite assieme è sempre 8. non appena seleziono più apparecchi, si scende a 5 o 6. Se prendo il contenuto di due apparecchi (attualmente contengono 12 test ciascuno) e rilasciarli in lo stesso apparecchio (per un totale di 24 test in quell'unica apparecchiatura) che l'apparecchiatura eseguirà sempre 8 test contemporaneamente.

Questo sembra dimostrare che non si tratta di un problema nei singoli test, ma piuttosto di come gli attributi del livello di assemblaggio percolano fino all'apparecchio o di come il corridore di test consuma tali attributi.

Inoltre, ho anche osservato (durante l'esecuzione di due proiettori) che una volta che uno dei due proiettori è stato eseguito nella sua interezza, il corridore inizia a eseguire più test contemporaneamente quando torna indietro a eseguire solo un faro. Per ora, il primo dispositivo viene eseguito quando ci sono 7 test da eseguire nella seconda partita. Non appena ciò accade, il numero di test eseguiti contemporaneamente salta dal precedente 5 o 6 al massimo disponibile di 7.

risposta

6

Secondo lo release note di Gallio v3.0.6:

MbUnit consente di sfruttare al meglio la CPU multi-core. Contrassegnare qualsiasi prova [Parallelizable] e sarà consentito di correre in parallelo con altri test parallelizzabili nello stesso apparecchio.

Programma possono anche essere marcati parallelizzabile per consentire loro di essere eseguito in parallelo con altri dispositivi parallelizzabili.

alt text

prega di notare che se si desidera che tutti i test all'interno di un apparecchio per essere considerato parallelizzabile quindi è ancora necessario aggiungere [Parallelizable] a ciascuno di essi. (Potremmo aggiungere una funzione per impostare questo al livello della vite o montaggio successiva sulla base del feedback dell'utente.)

noti inoltre che solo perché un test o l'apparecchio assegnati parallelizzabile non significa che verrà eseguito in parallelo con altri test in particolare. Per ragioni di efficienza, limitiamo il numero di thread test attivo sulla base del grado di parallelismo configurato. Se si desidera che un certo numero di istanze di un test per l'esecuzione in parallelo tra loro, considerare l'utilizzo di [ThreadedRepeat].

Il grado di parallelismo impostazione controlla il numero massimo di test che MbUnit tenterà di eseguire in parallelo tra loro. Di default, il grado di parallelismo è uguale al numero di CPU che hai o 2 al minimo.

Se non ti piace il default, allora è possibile ignorare il grado di parallelismo a livello di assemblaggio in questo modo:

alt text

Non so se aiuta. Forse Jeff potrebbe dare più dettagli come aveva implementato quella caratteristica.

+0

Penso che l'attributo Parallelizable a livello di assembly sia già implementato al 3.1 –

+0

3.1 è la versione che sto utilizzando.La documentazione (http://www.gallio.org/api/index.aspx) suggerisce che può essere fatto a livello di assemblaggio. L'unica cosa che noto è che la documentazione menziona la versione 3.2 non 3.1. Ma 3.2 non è ancora finito per quanto posso vedere. – BenA

+0

Per quanto ne so, si sta utilizzando l'API Parallelizable in modo corretto. Tieni presente che DegreeOfParallelism specifica solo il numero massimo di thread da utilizzare. Esistono vari motivi per cui i test non possono essere eseguiti in parallelo, come la struttura di nesting dei test, l'ordinamento dei test e le dipendenze di test. Alcuni costrutti come [Ripeti] non sono parallelizzati da [Parallelizzabile]. Allo stesso modo, le singole righe di test basati sui dati non sono parallele l'una con l'altra. (Sarebbe una bella caratteristica da aggiungere!) Se si imposta [DegreeOfParallelism (32)] si vedono più test simultanei in esecuzione in media? –

0

imbattuto in stesso problema, i miei risultati

  • [assembly: parallelizzabile (...)] presso le sostituzioni a livello di assieme di fissaggio attributi parallelizzabile e si tradurrà in Prove per l'elemento in esecuzione uno alla volta, ma a un appuntamento fisso livello parallelo. Sembra avere un massimo di 5-6 proiettori in parallelo.
  • [Parallelizable (TestScope.Descendants)] a livello di fixture farà sì che i proiettori vengano eseguiti uno alla volta ma i test vengano eseguiti in parallelo. Sembra non avere max test in parallelo.

definitiva a causa del vincolo livello di assieme ad innesto limiti paralleli, l'unico modo è quello di utilizzare attributi del livello di fissaggio e hanno infissi prove vengono in parallelo.

Suggerirei di creare un proiettore di dimensioni inferiori e più test per dispositivo per ovviare a questo problema. Potresti sempre lanciare più corridori per dispositivo di montaggio, forse.

La vergogna è questo il caso.

-1

Override non funziona per più di 5 test da eseguire alla volta. Abbiamo 25 sistemi su laboratori Sauce disponibili per eseguire 25 script alla volta, abbiamo superato il DegreeOfParallelism a 20 solo 5 eseguiti alla volta. [assembly: DegreeOfParallelism (20)] - Non funziona per Mbunit

+0

L'OP non è d'accordo con questo insieme alla maggior parte delle altre risposte –

Problemi correlati