Jak mogę przetestować dźwięk w urządzeniu?

Odziedziczyłem mały projekt i chcę go jednocześnie rozszerzyć i ustabilizować, pisząc Testy jednostkowe dla całego dodawanego przeze mnie kodu. Pierwsza klasa, TypedAudioCreatortworzy pliki audio i okazało się, że bardzo łatwo było najpierw przetestować i napisać kod na drugie.

Kiedy jednak przyszedł czas na pisanie TypedAudioPlayer, nie miałem pojęcia, jak to przetestować. To bardzo mała klasa skupiająca się na bardzo podstawowych podstawach odtwarzania dźwięku:

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

Nadal jestem bardzo nowy w TDD, ale zdaję sobie sprawę z korzyści płynących z tej praktyki i chciałbym spróbować ją poprawić. Najpierw napisałem Kod, nie ma tutaj testów, ale to był po prostu zbyt leniwy, że właściwie wymyśliłem sposób TDD na jego rozwiązanie. Pytanie brzmi: w jaki sposób powinienem / mógłbym przetestować tę klasę?

Jest wiele rzeczy „na krawędzi” większości systemów, których nie można odpowiednio przetestować jednostkowo. Na przykład wszystko, co produkuje grafikę lub dźwięk. W przypadku tego rodzaju systemów najlepiej jest przetestować ręcznie. Nawet przy zautomatyzowanym rozwiązaniu, wyniki te są przeznaczone do ludzkiej percepcji. Jedynym sposobem, aby wiedzieć, że osiągasz pożądany efekt, jest interakcja człowieka z nimi.

Może być możliwe wykonanie testu ręcznego, a następnie zapisanie wyniku tego testu ręcznego i utworzenie automatycznego testu, który zapewni, że dane wyjściowe się nie zmienią. Ostrzegamy jednak, że takie testy są niezwykle delikatne: każda zmiana w podstawowym kodzie może wymagać powtórzenia testu ręcznego, a następnie utworzenia nowego nagrania dla testu automatycznego.

Oczywiście trudno jest automatycznie przetestować, czy odtwarzacz audio naprawdę odtwarza dźwięk, ale i tak można tworzyć przydatne testy jednostkowe. Na przykład można przetestować, czy StartPlaying () powoduje zdarzenie StartedPlaying, a StopPlaying () powoduje zdarzenie StoppedPlaying. Możesz przetestować zachowanie podczas próby odtworzenia pustej listy odtwarzania lub pustej listy odtwarzania. Możesz przetestować, czy AddFile naprawdę dodaje plik do listy odtwarzania. Możesz przetestować, że po odtworzeniu pliku audio jest on usuwany z listy odtwarzania (jeśli jest to pożądane). Być może istnieją też przypadki naruszeń uszkodzonych plików audio itp., Które zasługują na przetestowanie.

Przeprowadzając testy jednostkowe tych rzeczy, możesz być pewien, że klasa zachowuje się dobrze, tj. Spełnia swoje umowy. Jeśli tak, ale nadal nie odtwarza dźwięku, jest to stosunkowo łatwe do złapania w testach ręcznych.

Należy pamiętać, że istnieje różnica między testowaniem jednostkowym , polegającym na pisaniu niewielkich testów testujących poszczególne jednostki kodu, a automatycznymi testami uruchomieniowymi, które uruchamiają testy jednostkowe, zwykle w ramach procesu kompilacji lub jakiegoś rodzaju ciągłego system integracyjny.

Testowanie jednostkowe jest zwykle zautomatyzowane, ale nadal może być wykonywane ręcznie. IEEE nie faworyzuje jednych nad drugimi. Celem testów jednostkowych jest izolacja jednostki i sprawdzenie jej poprawności. W ręcznym podejściu do testów jednostkowych można zastosować dokument instruktażowy krok po kroku.

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

Możesz łatwo napisać test jednostkowy, aby sprawdzić, czy komponent odtwarzacza audio prawidłowo odtwarza dźwięk:

1. Upewnij się, że głośniki działają, a głośność jest zwiększona.
2. Przejdź do folderu / my / test /.
3. Uruchom myTestRunner audioPlayerTest.script.thingee.
4. Powinieneś usłyszeć grę V Symfonii Beethovena przez 15 sekund.
5. Jeśli nic nie słyszałeś, dźwięk odtwarzany był mniej więcej 15 sekund lub był w jakikolwiek sposób zniekształcony, test nie powiódł się. W przeciwnym razie test przeszedł pomyślnie.

To, czego nie można łatwo zrobić, to włączyć ten test do zautomatyzowanego systemu testowego. Testy automatyczne to szczególna implementacja testów jednostkowych, ale nie jest to jedyna implementacja.

Zobacz także: /programming/1877118/is-unit-testing-always-automated