Conosci qualche framework xUnit che consente di eseguire test in parallelo, per utilizzare più core nella macchina di oggi?
Se nessuno (o così pochi) di loro lo fa, forse c'è una ragione ... È che i test sono solitamente così veloci che le persone semplicemente non sentono il bisogno di paralizzarli?
C'è qualcosa di più profondo che preclude la distribuzione (almeno alcuni) dei test su più thread?
NUnit 2.5 pNUnit in bundle che consente l'esecuzione di test in parallelo.
This release includes pNUnit, an extended NUnit runner for distributed parallel tests. The pNUnit program was developed at Codice Software for use in testing the Plastic SCM and has been contributed to NUnit. For more info about using pNUnit see the pNUnit site.
Il lato JUnit ha parallel-junit nonché amino .
Per rispondere alla seconda parte della tua domanda: C'è qualcosa di più profondo che preclude la distribuzione (almeno alcuni) dei test su più thread?
Gran parte del codice funziona solo quando viene eseguito un singolo thread. È banale produrre accidentalmente contese di risorse e deadlock quando si scrivono programmi supponendo che verranno eseguiti con un singolo thread. E questo funziona bene perché la maggior parte dei programmi esegue in realtà un singolo thread. Il parallelismo si ottiene eseguendo più copie o programmi diversi contemporaneamente (gli script Web sono un esempio comune - molti utenti che accedono a una singola pagina significano molte copie degli script per quella pagina che funzionano contemporaneamente).
Immagina una semplice classe "accedi al file". Quando si crea un'istanza si apre il file per la scrittura, quando si libera l'istanza si chiude il file. Quindi, il primo test crea un'istanza e inizia a eseguire un test. Il secondo test fa la stessa cosa in un secondo thread. E fallisce, perché la seconda istanza non può ottenere l'accesso in scrittura al file. Ma se si esegue uno alla volta, tutti i test passeranno.
Tutto questo può essere codificato in giro, e il semplice esempio potrebbe essere ottimizzato per funzionare. Ma farlo è probabilmente non necessario per il programma originale . Dovendo scrivere codice thread-safe solo così è possibile eseguire test di unità è irragionevole per molte persone. Quindi i test di unità multi-thread dovrebbero rimanere un extra opzionale.
Se i test devono configurare e interrogare un database, i test eseguiti in parallelo interferiscono tra loro a meno che non ci sia un database separato per ogni test eseguito in parallelo.
Anche se JUnit di per sé potrebbe non consentirlo (non ho una conoscenza intima delle sue ultime versioni), Maven con il suo plugin Surefire ha anche la possibilità di eseguire test in parallelo. Tuttavia, non l'ho ancora provato.
Non mi preme molto indagare su questa opzione, poiché abbiamo solo un po 'più di mille test e corrono abbastanza velocemente. Tuttavia, so che alcuni dei dispositivi di prova hanno dipendenze implicite tra (abbiamo trovato alcune di queste dipendenze quando alcuni test si sono interrotti inaspettatamente in passato), quindi c'è il rischio che parallelamente i test facciano in modo che alcuni di essi falliscano in modo imprevedibile. Si può dire che va bene poiché rende esplicito il problema. Tuttavia, abbiamo a che fare con un sistema legacy e abbiamo molte altre questioni importanti da affrontare: il tempo è una risorsa scarsa (come al solito).
La codifica multi-thread non è banale. Anche se fatti da persone che sanno cosa stanno facendo, possono verificarsi dei bug dipendenti dal timing. Sono difficili da sistemare. Avendo affrontato quello che possono produrre migliaia di tipi di bug multi-battistrada, preferirei non averli nel mio framework di test. La prima correzione che mi è sembrata funzionasse, ma a seguito di ulteriori test è emerso che era appena diventato un bug su decine di migliaia.
Le tecniche per fare multi-threading su multi processori stanno migliorando con l'avvento dei PC multiprocessore. Tuttavia, ci vorrà del tempo prima che siano ampiamente utilizzati.
Alcune suite di test hanno dipendenze tra i test che non devono essere esplicitamente dichiarati quando i test vengono eseguiti in un singolo flusso. Tuttavia, su un motore multi-vapore, dovrebbero essere esplicitamente indicati. (Dove queste dipendenze dovrebbero esistere è una domanda diversa.)
Da un altro punto di vista, alcune cose non hanno bisogno di essere eseguite in parallelo. Il processo viene eseguito in modo sufficientemente rapido, potrebbe essere meglio concentrare gli sforzi su cose diverse dall'implementazione del multi-threading.
MBUnit è in grado di eseguire test in parallelo semplicemente specificando alcuni attributi a livello di assieme.
[assembly: DegreeOfParallelism(6)]
[assembly: Parallelizable(TestScope.All)]
Ho usato quel progetto per eseguire i test di selenio in parallelo con successo per qualche tempo. Sfortunatamente il progetto non è più molto vivo.
xUnit 2.0 dovrebbe anche supportare il test delle unità parallele ma non l'ho ancora provato.
Leggi altre domande sui tag xunit multithreading tests