オーディオを単体テストするにはどうすればよいですか？

私は小さなプロジェクトを継承しており、追加するすべての新しいコードの単体テストを作成して、プロジェクトを拡張し、同時に安定させたいと考えています。最初のクラス、TypedAudioCreatorはオーディオファイルを作成し、これは最初にテストし、2番目のコードを書くのが非常に簡単であることが判明しました。

しかし、書くときが来たとき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の解決方法を適切に考えるのが面倒でした。私が持っている質問は、このクラスをどのようにテストする必要がありますか？

ユニットテストを適切に行うことができないほとんどのシステムには、「端に」あることがたくさんあります。たとえば、グラフィックスやサウンドを生成するもの。これらの種類のシステムでは、おそらく手動テストが最適です。自動化されたソリューションであっても、これらの出力は人間の知覚用です。あなたが望ましい効果を生み出していることを知る唯一の方法は、人間にそれらと相互作用させることです。

手動テストを実行してから、その手動テストの出力を記録し、出力が変わらないことを保証する自動テストを作成することができます。ただし、これらのテストは非常に脆弱であることに注意してください。基盤となるコードを変更するには、手動テストを繰り返してから、自動テストの新しい記録を作成する必要があります。

audioplayerが本当にオーディオを再生するかを自動的にテストすることは明らかに困難ですが、とにかく便利なユニットテストを作成できます。たとえば、StartPlaying（）がStartedPlayingイベントを引き起こし、StopPlaying（）がStoppedPlayingイベントを引き起こすことをテストできます。空のプレイリストまたはヌルプレイリストを再生するときに、動作をテストできます。AddFileが実際にファイルをプレイリストに追加することをテストできます。オーディオファイルを再生した後、プレイリストから削除されることをテストできます（必要な場合）。たぶん、テストに値する壊れたオーディオファイルなどのコーナーケースもあります。

これらのユニットテストを行うことで、クラスが適切に動作すること、つまりその契約を満たしていることを確認できます。正常に動作するが、音が再生されない場合は、手動テストで比較的簡単にキャッチできます。

単体テストには違いがあることに注意してください（コードの個々のユニットをテストする小さなテストを記述する行為）と、通常ビルドプロセスの一部として、または何らかの連続的なユニットテストを実行する自動テストランナーがあることに注意してください統合システム。

単体テストは一般的に自動化されていますが、それでも手動で実行できます。IEEEは一方を他方よりも優先しません。ユニットテストの目的は、ユニットを分離し、その正当性を検証することです。単体テストへの手動のアプローチでは、段階的な説明文書を使用できます。

（ http://en.wikipedia.org/wiki/Unit_testing#Techniques）

オーディオプレーヤーコンポーネントがオーディオを正しく再生することをテストするユニットテストを簡単に作成できます。

1. スピーカーが機能し、音量が上がっていることを確認してください。
2. / my / test / folderに移動します。
3. myTestRunner audioPlayerTest.script.thingeeを実行します。
4. ベートーベンの5回目の交響曲の演奏が15秒間聞こえます。
5. 何も聞こえなかった場合、オーディオが15秒以上または15秒未満で再生された、または何らかの形で歪んだ場合、テストは失敗しました。それ以外の場合、テストに合格しました。

簡単にできないのは、そのテストを自動テストシステムに含めることです。自動テストは単体テストの特定の実装ですが、実装はそれだけではありません。

参照：https : //stackoverflow.com/questions/1877118/is-unit-testing-always-automated