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

13

He heredado un pequeño proyecto y quiero extenderlo y estabilizarlo al mismo tiempo escribiendo Pruebas unitarias para todos los nuevos códigos que estoy agregando. La primera clase, TypedAudioCreator , crea archivos de audio y resultó ser muy fácil de probar primero y escribir el código para la segunda.

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 mejorarlo. He escrito Código primero, no hay pruebas aquí, pero eso era solo que soy demasiado perezoso para pensar correctamente en la forma TDD de resolverlo. La pregunta que tengo es, ¿cómo debería / podría probar esta clase?

    
pregunta IAE 20.02.2012 - 06:10

3 respuestas

10

Hay muchas cosas "en los bordes" de la mayoría de los sistemas que no se pueden probar de forma adecuada. Por ejemplo, cualquier cosa que produzca gráficos o sonido. Para este tipo de sistemas, probablemente lo mejor sea realizar 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.

Puede ser posible realizar una prueba manual, luego registrar la salida de esa prueba manual y crear una prueba automatizada que asegure que la salida no cambie. 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.

    
respondido por el Chris Pitman 20.02.2012 - 07:13
9

Obviamente, es difícil probar automáticamente que el reproductor de audio realmente reproduce audio, pero puedes crear pruebas de unidad útiles de todos modos. Por ejemplo, puede probar que StartPlaying () provoca el evento StartedPlaying, y StopPlaying () provoca el evento StoppedPlaying. Puede probar el comportamiento cuando intenta reproducir una lista de reproducción vacía o una lista de reproducción nula. Puedes 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 lo desea). Es posible que existan puntos clave para los archivos de audio rotos, etc. que también merecen ser probados.

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, es relativamente fácil de detectar en las pruebas manuales.

    
respondido por el user281377 20.02.2012 - 09:39
3

Tenga en cuenta que hay una diferencia entre Unit Testing , que consiste en escribir pequeñas pruebas que prueban unidades individuales de su código, y Automated Test Runners que ejecute sus pruebas unitarias, generalmente como parte del proceso de compilación o algún tipo de sistema de integración continua.

  

La prueba de la unidad se suele automatizar, pero aún puede realizarse de forma manual. El IEEE no favorece a uno sobre el otro. El objetivo de 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.

( enlace )

Puede escribir fácilmente una prueba de unidad 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é alto.
  2. Vaya a / mi / prueba / carpeta.
  3. Ejecutar myTestRunner audioPlayerTest.script.thingee.
  4. Deberías escuchar la 5ta Sinfonía de Beethoven durante 15 segundos.
  5. Si no escuchó nada, el audio se escuchó durante 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 implementación only .

Vea también: enlace

    
respondido por el lfalin 08.01.2015 - 15:45

Lea otras preguntas en las etiquetas