¿Cómo puedo probar el audio de la unidad?

He heredado un pequeño proyecto y quiero extenderlo y estabilizarlo al mismo tiempo escribiendo Pruebas unitarias para todo el nuevo código que estoy agregando. La primera clase, TypedAudioCreatorcrea archivos de audio y esto resultó ser muy fácil de probar primero y escribir código para el segundo.

Sin embargo, cuando llegó el momento de escribir TypedAudioPlayer, no tenía idea de cómo podría probarlo. Es una clase muy pequeña que se centra en los conceptos básicos de la reproducción de sonido:

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);
    }
}

Todavía soy muy nuevo en TDD, pero me doy cuenta de los beneficios de la práctica y me gustaría intentar mejorar. He escrito Code primero, no hay pruebas aquí, pero eso fue solo que yo era demasiado vago para pensar adecuadamente en la forma TDD de resolverlo. La pregunta que tengo es, ¿cómo debería / podría probar esta clase?

Hay muchas cosas "en los bordes" de la mayoría de los sistemas que no se pueden probar adecuadamente en la unidad. Por ejemplo, cualquier cosa que produzca gráficos o sonido. Para este tipo de sistemas, probablemente sea mejor con las pruebas manuales. Incluso dada una solución automatizada, estos resultados están destinados a la percepción humana. La única forma de saber que estás produciendo el efecto deseado es hacer que un humano interactúe con ellos.

Es posible realizar una prueba manual, luego registrar la salida de esa prueba manual y crear una prueba automatizada que garantice que la salida no cambie. Sin embargo, tenga en cuenta que las pruebas como estas son increíblemente frágiles: cualquier cambio en el código subyacente puede requerir una repetición de la prueba manual y luego crear una nueva grabación para la prueba automatizada.

Obviamente, es difícil probar automáticamente que el reproductor de audio realmente reproduce audio, pero de todos modos puede crear pruebas unitarias útiles. Por ejemplo, puede probar que StartPlaying () causa el evento StartedPlaying y StopPlaying () causa el evento StoppedPlaying. Puede probar el comportamiento cuando intente reproducir una lista de reproducción vacía o una lista de reproducción nula. Puede probar que AddFile realmente agrega el archivo a la lista de reproducción. Puede probar que después de reproducir un archivo de audio, se elimina de la lista de reproducción (si se desea). Tal vez hay casos de esquina para archivos de audio rotos, etc., que también merecen una prueba.

Al tener pruebas unitarias para esas cosas, puede estar seguro de que la clase se comporta bien, es decir, cumple con sus contratos. Si lo hace, pero aún no reproduce sonido, eso es relativamente fácil de atrapar en las pruebas manuales.

Tenga en cuenta que existe una diferencia entre las pruebas unitarias , que es el acto de escribir pequeñas pruebas que prueban unidades individuales de su código, y los corredores de prueba automatizados que ejecutan sus pruebas unitarias, generalmente como parte del proceso de construcción o algún tipo de continuo Sistema de integración.

Las pruebas unitarias suelen ser automatizadas, pero aún pueden realizarse manualmente. El IEEE no favorece a uno sobre el otro. El objetivo en las pruebas unitarias es aislar una unidad y validar su corrección. Un enfoque manual para las pruebas unitarias puede emplear un documento instructivo paso a paso.

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

Puede escribir fácilmente una prueba unitaria para probar que un componente del reproductor de audio reproduce audio correctamente:

1. Asegúrese de que sus altavoces estén funcionando y que el volumen esté subido.
2. Vaya a / mi / prueba / carpeta.
3. Ejecute myTestRunner audioPlayerTest.script.thingee.
4. Deberías escuchar la quinta sinfonía de Beethoven durante 15 segundos.
5. Si no escuchó nada, el audio se reprodujo más o menos de 15 segundos o se distorsionó de alguna manera, la prueba falló. De lo contrario, la prueba pasó.

Lo que no puede hacer fácilmente es incluir esa prueba en un sistema de prueba automatizado. Las pruebas automatizadas son una implementación particular de las pruebas unitarias, pero no es la única implementación.

Ver también: /programming/1877118/is-unit-testing-always-automated