Как я могу протестировать звук?

Я унаследовал небольшой проект и хочу одновременно его расширить и стабилизировать, написав модульные тесты для всего нового кода, который я добавляю. Первый класс TypedAudioCreatorсоздает аудиофайлы, и это оказалось очень легко проверить первым и написать код для второго.

Однако когда пришло время писать TypedAudioPlayer, я понятия не имел, как можно это проверить. Это очень маленький класс, фокусирующийся на самых основах воспроизведения звука:

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

Я все еще очень новичок в TDD, но я понимаю преимущества практики и хотел бы попытаться улучшить ее. Сначала я написал «Код», здесь никаких тестов, но я просто слишком ленив, чтобы правильно подумать о способе его решения TDD. Вопрос, который у меня возник, заключается в следующем: как я могу / могу проверить этот класс?

В большинстве систем существует множество «краев», которые не могут быть адекватно протестированы на модульном уровне. Например, все, что производит графику или звук. Для таких систем лучше всего проводить ручное тестирование. Даже учитывая автоматизированное решение, эти результаты предназначены для человеческого восприятия. Единственный способ узнать, что вы производите желаемый эффект - это заставить человека взаимодействовать с ними.

Может быть возможным выполнить ручной тест, затем записать результаты этого ручного теста и создать автоматический тест, который гарантирует, что выходные данные не изменятся. Имейте в виду, что подобные тесты невероятно хрупкие: любое изменение базового кода может потребовать повторения ручного теста, а затем создания новой записи для автоматического теста.

Очевидно, что сложно автоматически проверить, что аудиоплеер действительно воспроизводит звук, но вы все равно можете создать полезные модульные тесты. Например, вы можете проверить, что StartPlaying () вызывает событие StartedPlaying, а StopPlaying () вызывает событие StoppedPlaying. Вы можете проверить поведение при попытке воспроизведения пустого списка воспроизведения или нулевого списка воспроизведения. Вы можете проверить, что AddFile действительно добавляет файл в список воспроизведения. Вы можете проверить, что после воспроизведения аудиофайла он удаляется из списка воспроизведения (если это необходимо). Может быть, есть угловые шкафы для сломанных аудио файлов и т. Д., Которые заслуживают тестирования.

Имея модульные тесты для этих вещей, вы можете быть уверены, что класс ведет себя хорошо, то есть выполняет свои контракты. Если это произойдет, но звук по-прежнему не воспроизводится, это сравнительно легко обнаружить в ручных тестах.

Имейте в виду, что существует разница между модульным тестированием , которое заключается в написании небольших тестов, которые тестируют отдельные модули вашего кода, и автоматизированными тестовыми прогонами которые запускают ваши модульные тесты, как правило, как часть процесса сборки или какого-либо непрерывного система интеграции.

Модульное тестирование обычно автоматизировано, но все же может выполняться вручную. IEEE не одобряет одно над другим. Цель юнит-тестирования состоит в том, чтобы изолировать юнит и проверить его правильность. Ручной подход к модульному тестированию может использовать пошаговый инструктивный документ.

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

Вы можете легко написать модульный тест, чтобы проверить, что компонент аудиоплеера воспроизводит аудио правильно:

1. Убедитесь, что ваши колонки работают и громкость увеличена.
2. Перейдите в папку / my / test /.
3. Выполните myTestRunner audioPlayerTest.script.thingee.
4. Вы должны услышать игру 5-й симфонии Бетховена в течение 15 секунд.
5. Если вы ничего не слышали, звук воспроизводился более или менее 15 секунд или был искажен каким-либо образом, тест не прошел. В противном случае тест пройден.

То, что вы не можете легко сделать, это включить этот тест в автоматизированную систему тестирования. Автоматизированное тестирование - это особая реализация модульного тестирования, но это не единственное реализация.

Смотрите также: /programming/1877118/is-unit-testing-always-automated