2010-12-15 33 views
6

Ho solo bisogno di unit test alcuni metodi come questo:Thread di test unitario?

public void start() 
{ 
    myThread.Start(); 
} 

public void stop() 
{ 
    myThread.Abort(); 
} 

Come posso fare questo? Potrei chiamare il metodo start e verificare IsAlive == true ma il thread continua a funzionare in background e chiama il suo metodo. Un altro modo è chiamare start e poi fermarsi immediatamente, ma non è pulito perché sarebbe come se stessi testando due cose. È così semplice ma arghh!

risposta

0

Perché avete bisogno di test di unità questi metodi? Cosa stai cercando di verificare? Altri test si interrompono se la cosa che stai cercando di verificare non è vera? (IE è coperto da altri test?)

In caso contrario, è possibile ottenere in semafori e fare il test dell'unità assicurarsi che il thread avviato prima di un determinato timeout, ma io non penso che sia un valore estremamente prezioso prova alla fine. Non aumenterebbe molto la mia fiducia.

2

È una buona idea rendere le cose dipendenti dalla temporizzazione in modo sincrono ai fini del test. (Effettivamente, è una buona idea localizzare interazioni dipendenti dal tempo anche in uso non test.)

Se si vuole veramente controllare che questi metodi avviano e interrompano un thread, vorrei inserire un oggetto fittizio myThread che fornisce questi metodi, ma in realtà non inizia una discussione, o una discussione il cui codice si limiterà a sedersi e attendere senza fare nulla. Quindi puoi registrare che è iniziato e fermato, senza preoccuparti della complessità di ciò che farà il tuo thread reale.

Forse la tua situazione è più complessa del semplice controllo del thread avviato? Potrebbe essere utile se tu pubblichi un esempio leggermente più grande del tipo di cosa che vuoi testare.

1

Sono d'accordo con BnWasteland che per l'esempio di codice dato l'unica cosa che si può verificare è che System.Threading.Thread.Start e System.Threading.Thread.Abort funzionano correttamente. Quindi sarebbe ragionevole presumere che siano e si concentrino sul proprio codice dell'applicazione. Quindi hai due domini:

1) Il codice del compito effettivo che viene eseguito all'interno del thread. Questo può essere testato in un normale test unitario.

2) Assicurarsi che l'infrastruttura con multithreading funzioni come previsto.

(2) tende di più alla categoria di test di integrazione ma nessuno vieta l'utilizzo di Unit-tesitng framework per questo. E in questo caso è bene fare Start/Stop e anche farlo più volte con alcuni carichi di lavoro randomizzati solo per assicurarsi che il sistema si comporti e porti a termine il lavoro. Questo ovviamente va alla prova "più lunga" che non è necessario eseguire ad ogni check-in.

6

Il trucco è separare il comportamento asincrono dalla logica. Osserva che la tua logica effettiva è sincrona e che la parte asincrona è semplicemente un "tempo di attesa" nel mezzo.

Il libro xUnit Test Patterns lo descrive bene. È anche un modello - Humble Object. È spiegato in questo modo meglio di me.