Test per un deadlock con nUnit
-
19-08-2019 - |
Domanda
Sono nuovo di unit test e nUnit (2.48). Vorrei scrivere un metodo di prova in cui il caso di errore è che si blocca. È possibile? Ovviamente nUnit non sa per impostazione predefinita quanto tempo dovrebbe impiegare il metodo per eseguire, quindi dovrei scrivere il codice per fare il lavoro su un thread separato e quindi interromperlo e lanciare ed eccezione se ci fosse voluto più tempo di quanto io definisca? C'è un modo migliore per farlo?
Grazie
Soluzione
È possibile ma potrebbe non essere la cosa migliore da fare. I test unitari non sono davvero adatti per testare il comportamento della concorrenza, sfortunatamente non ci sono molti metodi di test adatti.
NUnit non fa nulla con i thread. È possibile scrivere test che avviano diversi thread e quindi testare la loro interazione. Ma questi inizierebbero ad assomigliare più ai test di integrazione che ai test unitari.
Un altro problema è che il comportamento dei deadlock di solito dipende dall'ordine in cui sono pianificati i thread. Quindi sarebbe difficile scrivere un test conclusivo per testare un certo problema di deadlock perché non hai alcun controllo sulla pianificazione dei thread, questo è fatto dal sistema operativo. Potresti finire con test che a volte falliscono su processori multicore ma riescono sempre su processori single core.
Altri suggerimenti
Beh, è ??certamente possibile verificare un deadlock eseguendo il codice su un altro thread e vedendo se ritorna in modo tempestivo. Ecco un codice di esempio (molto semplice):
[TestFixture]
public class DeadlockTests
{
[Test]
public void TestForDeadlock()
{
Thread thread = new Thread(ThreadFunction);
thread.Start();
if (!thread.Join(5000))
{
Assert.Fail("Deadlock detected");
}
}
private void ThreadFunction()
{
// do something that causes a deadlock here
Thread.Sleep(10000);
}
}
Non vorrei dire che questo è il "modo migliore", ma è quello che ho trovato utile in alcune occasioni.
Il rilevamento di deadlock equivale al problema di arresto , e pertanto attualmente non risolvibile nel caso generale .
Se hai un problema specifico da evitare, potrebbero esserci degli hack specifici per ottenere almeno un minimo di sicurezza. Tieni presente, tuttavia, che questo può essere solo un trucco e mai al 100%. Ad esempio, un test del genere può sempre passare sulla macchina di sviluppo ma mai sulla macchina di produzione.
Dai un'occhiata al progetto Microsoft chiamato " Scacchi " ;. È progettato per trovare bug consentiti http://research.microsoft.com/en- noi / progetti / scacchi /
Per verificare un deadlock, è necessario implementare un grafico di stato e un controllo dei cicli nel grafico di stato corrente nel test unitario. Il grafico dello stato è costituito dalle risorse come nodi e dalle dipendenze come bordi. Non ho idea dell'implementazione di una cosa del genere, ma questa è la teoria.
Un test unitario verifica la correttezza dell'ingresso e dell'output dei dati (principalmente per il punto successivo) e non la correttezza del flusso di esecuzione dell'applicazione.
L'idea di Mark Heath sembra ragionevole, ma accademicamente sbagliata.