Che cosa è il modo migliore per unità di test da più thread?

Question

questo tipo di è il seguito di un altro domanda di mio.

In sostanza, una volta che ho il codice per l'accesso al file (esaminerà le risposte in un minuto) quale sarebbe il modo migliore per prova esso?

Sto pensando di creare un metodo che solo genera un sacco di BackgroundWorker's o qualcosa del genere e dice loro di caricare/salvare il file e prova con diversi file/dimensioni dell'oggetto.Quindi, ottenere una risposta dal thread per vedere se per caso non riuscite riuscito/il mondo implode etc.

Può voi offrire suggerimenti sul modo migliore per avvicinarsi a questo?Come ho detto prima, questo è il genere di nuovo per me :)

Modifica

Di seguito ajmastrean s post:

Io sto usando una console app per i test di Debug.Afferma :)

---

Aggiornamento

Originariamente ho arrotolato con l'utilizzo di BackgroundWorker per affrontare con la filettatura (dato che io sono abituato da Windows dev), ben presto ho capito che quando avevo l'esecuzione di prove in cui più di ops (thread) necessari per completare prima di continuare, ho capito che sarebbe stato un po ' un hack per fare questo.

Ho poi seguito ajmastrean's post e mi sono reso conto che in realtà dovrebbe essere utilizzando il Thread classe per lavorare con operazioni simultanee.Io ora refactor utilizzando questo metodo (anche se un approccio diverso).

Answer 1

In .NET, ThreadPool thread di non ritorno, senza la creazione di ManualResetEvents o AutoResetEvents.Trovo queste eccessivo per un rapido metodo di prova (per non parlare di un po ' complicata per creare, impostare e gestire).Operaio di sfondo è un po ' più complessa con il callback e tale.

Qualcosa che ho trovato che funziona è

1. Creare un array di thread.
2. Il programma di installazione ThreadStart il metodo di ogni thread.
3. Inizio di ogni thread.
4. Aderire su tutti i thread (blocchi il thread corrente fino a quando tutti gli altri thread completo o abort)

public static void MultiThreadedTest()
{
    Thread[] threads = new Thread[count];

    for (int i = 0; i < threads.Length; i++)
    {
        threads[i] = new Thread(DoSomeWork());
    }

    foreach(Thread thread in threads)
    {
        thread.Start();
    }

    foreach(Thread thread in threads)
    {
        thread.Join();
    }
}

Answer 2

@ajmastrean, in quanto unità di risultato del test deve essere prevedibile, abbiamo bisogno di sincronizzare i thread in qualche modo.Non riesco a vedere un modo semplice per farlo senza l'utilizzo di eventi.

Ho trovato che ThreadPool.QueueUserWorkItem dà un modo semplice per testare i casi di utilizzo

 ThreadPool.QueueUserWorkItem(x => { 
    File.Open(fileName, FileMode.Open);
    event1.Set(); // Start 2nd tread;
    event2.WaitOne(); // Blocking the file;
});
ThreadPool.QueueUserWorkItem(x => { 
    try
    {
        event1.WaitOne(); // Waiting until 1st thread open file
        File.Delete(fileName); // Simulating conflict
    }
    catch (IOException e)
    {
        Debug.Write("File access denied");
    }
});

Answer 3

La tua idea dovrebbe funzionare bene.Fondamentalmente si desidera solo per la generazione di un fascio di fili, e assicurarsi che quelli di scrittura il file di prendere abbastanza a lungo per farlo effettivamente rendere i lettori di attendere.Se tutti i thread di ritorno senza errori e senza bloccare per sempre, allora il test ha esito positivo.