Come posso testare l'audio dell'unità?

Question

Come posso testare l'audio dell'unità?

#1 da (10 voti)
#2 da (9 voti)
#3 da (3 voti)

13

Ho ereditato un piccolo progetto e voglio estenderlo e stabilizzarlo allo stesso tempo scrivendo Test di unità per tutto il nuovo codice che sto aggiungendo. La prima classe, TypedAudioCreator , crea file audio e questo si è rivelato molto facile da testare prima e scrivere codice per secondo.

Tuttavia, quando è arrivato il momento di scrivere TypedAudioPlayer , non avevo idea di come avrei potuto testarlo. È una classe molto piccola incentrata sulle basi del suono:

public class TypedAudioFilePlayer
{
    public event StartedPlayingHandler StartedPlaying;
    public event StoppedPlayingHandler StoppedPlaying;

    public readonly int TimeBetweenPlays;

    private Queue<TypedAudioFile> _playlist = new Queue<TypedAudioFile>(); 

    public TypedAudioFilePlayer(int timeBetweenPlays)
    {
        TimeBetweenPlays = timeBetweenPlays;
    }

    public void AddFile(TypedAudioFile file)
    {
        _playlist.Enqueue(file);
    }

    public void StartPlaying()
    {
        ThreadPool.QueueUserWorkItem(ignoredState =>
        {
            while (_playlist.Count > 0)
            {
                var audioFile = _playlist.Dequeue();

                if (StartedPlaying != null)
                    StartedPlaying(audioFile);

                audioFile.SoundPlayer.PlaySync();
                audioFile.SoundPlayer.Dispose();

                if (StoppedPlaying != null)
                    StoppedPlaying(audioFile);
            }
        });
    }

    public void StopPlaying()
    {
        if (StoppedPlaying != null)
            StoppedPlaying(null);
    }
}

Sono ancora molto nuovo al TDD, ma realizzo i benefici della pratica e vorrei provare a migliorare. Prima ho scritto Codice, non ci sono test, ma ero solo troppo pigro per pensare correttamente al modo TDD di risolverlo. La domanda che ho è, come dovrei / potrei testare questa lezione?

tdd c#

posta IAE 20.02.2012 - 06:10

fonte

3 risposte

Leggi altre domande sui tag tdd c#

XSLT e possibili alternative [chiuso] Quando dovrei usare l'operatore di conversione di tipo implicito di C #?

score 10 · Answer 1

Ci sono molte cose "ai margini" della maggior parte dei sistemi che non possono essere adeguatamente testati. Ad esempio, tutto ciò che produce grafica o suono. Per questi tipi di sistemi, probabilmente stai meglio con i test manuali. Anche in presenza di una soluzione automatizzata, queste uscite sono pensate per la percezione umana. L'unico modo per sapere che stai producendo l'effetto desiderato è avere un umano che interagisca con loro.

Potrebbe essere possibile eseguire un test manuale, quindi registrare l'output di quel test manuale e creare un test automatico che garantisca che l'output non cambi. Attenzione però che test come questi sono incredibilmente fragili: qualsiasi modifica al codice sottostante potrebbe richiedere una ripetizione del test manuale e quindi la creazione di una nuova registrazione per il test automatico.

score 9 · Answer 2

Ovviamente è difficile verificare automaticamente che l'audioplayer realmente riproduca audio, ma è comunque possibile creare test unitari utili. Ad esempio, è possibile verificare che StartPlaying () causi l'evento StartedPlaying e StopPlaying () causi l'evento StoppedPlaying. È possibile testare il comportamento quando si tenta di riprodurre una playlist vuota o una playlist nullo. È possibile verificare che AddFile aggiunga realmente il file alla playlist. È possibile verificare che, dopo aver riprodotto un file audio, venga rimosso dalla playlist (se lo si desidera). Forse ci sono anche cornette per file audio rotti ecc. Che meritano di essere testati.

Avendo test unitari per queste cose, puoi essere sicuro che la classe si comporta bene, cioè soddisfa i suoi contratti. Se lo fa, ma continua a non emettere suoni, è relativamente facile da catturare nei test manuali.

score 3 · Answer 3

Ricorda che c'è una differenza tra Test dell'unità , che è l'atto di scrivere piccoli test che testano le singole unità del tuo codice e Test runner automatizzati che esegui i tuoi test unitari, solitamente come parte del processo di costruzione o di un qualche tipo di sistema di integrazione continua.

Unit testing is commonly automated, but may still be performed manually. The IEEE does not favor one over the other. The objective in unit testing is to isolate a unit and validate its correctness. A manual approach to unit testing may employ a step-by-step instructional document.

( link )

Puoi facilmente scrivere un test unitario per verificare che un componente del lettore audio riproduca correttamente l'audio:

Assicurati che i tuoi altoparlanti funzionino e il volume sia alzato.
Vai a / my / test / cartella.
Esegui myTestRunner audioPlayerTest.script.thingee.
Dovresti ascoltare la 5a Sinfonia di Beethoven suonare per 15 secondi.
Se non hai sentito nulla, l'audio ha giocato più o meno di 15 secondi, o è stato distorto in alcun modo, il test non è riuscito. Altrimenti, il test è passato.

Ciò che non puoi fare facilmente è includere quel test in un sistema di test automatizzato. La verifica automatizzata è una particolare implementazione del test delle unità, ma non è l'implementazione solo .

Vedi anche: link