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

È stato utile?

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.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top