Come posso testare l'audio dell'unità?

Ho ereditato un piccolo progetto e desidero estenderlo e stabilizzarlo allo stesso tempo scrivendo Unit Test per tutto il nuovo codice che sto aggiungendo. La prima classe, TypedAudioCreatorcrea file audio e questo si è rivelato molto facile testare prima e scrivere codice per secondo.

Tuttavia, quando è arrivato il momento di scrivere TypedAudioPlayer, non avevo idea di come poterlo testare. È una classe molto piccola focalizzata 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 in TDD, ma mi rendo conto dei benefici della pratica e vorrei provare a migliorarlo. Ho scritto prima Code, nessun test qui, ma ero solo troppo pigro per pensare correttamente al modo TDD di risolverlo. La domanda che ho è: come dovrei / potrei testare questa classe?

Ci sono molte cose "ai margini" della maggior parte dei sistemi che non possono essere adeguatamente testate dall'unità. Ad esempio, tutto ciò che produce grafica o suono. Per questi tipi di sistemi, probabilmente è meglio provare manualmente. Anche data una soluzione automatizzata, questi risultati sono pensati per la percezione umana. L'unico modo per sapere che stai producendo l'effetto desiderato è far interagire un essere umano con loro.

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

È ovviamente difficile testare automaticamente che l'audioplayer riproduca realmente l' audio, ma puoi comunque creare utili test unitari. 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 null. Puoi provare che AddFile aggiunge davvero il file alla playlist. Puoi provare che dopo aver riprodotto un file audio, questo viene rimosso dalla playlist (se lo desideri). Forse ci sono anche cornici per file audio rotti, ecc. Che meritano di essere testati.

Avendo test unitari per queste cose, puoi essere sicuro che la classe si comporti bene, cioè soddisfi i suoi contratti. Se lo fa, ma non riproduce ancora alcun suono, è relativamente facile da catturare nei test manuali.

Tieni presente che esiste una differenza tra Unit Testing , che è l'atto di scrivere piccoli test che testano singole unità del tuo codice e automatizzati Test Runner che eseguono i tuoi test di unità, di solito come parte del processo di generazione o in qualche tipo di continuo sistema di integrazione.

I test unitari sono comunemente automatizzati, ma possono comunque essere eseguiti manualmente. L'IEEE non favorisce l'uno rispetto all'altro. L'obiettivo del test unitario è isolare un'unità e verificarne la correttezza. Un approccio manuale ai test unitari può impiegare un documento di istruzioni passo-passo.

( http://en.wikipedia.org/wiki/Unit_testing#Techniques )

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

1. Assicurati che gli altoparlanti funzionino e che il volume sia alzato.
2. Vai alla cartella / my / test /.
3. Esegui myTestRunner audioPlayerTest.script.thingee.
4. Dovresti ascoltare la quinta Sinfonia di Beethoven suonare per 15 secondi.
5. Se non si sente nulla, l'audio viene riprodotto più o meno di 15 secondi o è stato distorto in alcun modo, il test ha avuto esito negativo. Altrimenti, il test è passato.

Quello che non puoi facilmente fare è includere quel test in un sistema di test automatizzato. Il testing automatizzato è un'implementazione particolare del test unitario, ma non è l' unica implementazione.

Vedi anche: /programming/1877118/is-unit-testing-always-automated