CDを無駄にすることなくCDを作成するソフトウェアをテストする方法は？

CD（音楽）の書き込みに使用できるアプリケーションを作成したい。とにかく実際のCDでテストする必要があることは知っていますが、小さな変更を加えるたびにこれを行いたくありません。しかし、正しいデータが書き込まれるかどうかを知り、テストしたいので、破損したCDを取得することはありません。

物理ドライブに直接書き込むAPIのみを公開するライブラリを使用しています。ディスクイメージに書き込むことはできません（テストがはるかに簡単になります）。

CDを無駄にせずにこれをテストするにはどうすればよいですか？

多くの場合、簡単な答えが最良です。書き換え可能なCDですか？

また、時間を節約するために、比較的小さなファイルを作成します。大きなファイルを頻繁に実行するだけです。

Linuxを使用している場合は、単なる名前付きパイプである「cdデバイス」をセットアップできるはずです。apiが「デバイス」に書き込み、もう一方の端をプログラムにフックして、それが何をするのかを見たり、ディスクイメージに変換したりできるようにします。たくさんのオプションがあります。この記事をご覧ください 名前付きパイプの詳細を。

ケビンの答えは、はるかに簡単なIMOです。

ライブラリのAPIのモックを使用するテストをできるだけ多く記述します。これにより、ユニットでコードをテストできます。これは、ライブラリが想定された方法で実行されると仮定して、コードがコード内で機能することを示しています。

ある時点で、実際にライブラリを使用する統合テストを行う必要があります。しかし、ポイントは、このポイントに到達する前に、あなた自身のコードにすでにある程度の自信があるということです。あなたが見たように、統合テストはしばしばより多くの時間とリソースを必要とします。そのため、徹底した単体テストでは、統合テストに完全に依存することはできません。

正確に何のテストについて話しているのですか？

あなたの質問で「小さな変更をするたびにこれをしたくない」と読んで、あなたはユニットテストについて話していると思います。

ただし、後で、CDへのデータの書き込みを担当するAPIを使用していることを追加します。このAPIが正しくテストおよび文書化されていれば、CDにデータを書き込む実際のプロセスに対処する必要はなく、テストする必要もありません。この場合、「小さな変更を行うたびに」行う必要がない統合テストを処理します。

WTP、

Chrisが指摘したように、ソフトウェア（APIやレコーダーではなく）をテストしたいので、APIのモックが必要になります。
統合テストの場合、信頼できる「ISO」レコーダーを使用すると、.isoファイルを分析してCDコンテンツのテストを自動化できます。
実際にCDまたはDVDを作成しても、最終的な結果は得られません。なぜなら、エラーの原因がCDの欠陥か、レコーダーの欠陥か、ソフトウェアのバグかを判断できないためです。同じディスク（明らかにそうではない）。
幸運を！