現在、epub ファイル (基本的にはいくつかの xml メタデータ ファイルを含む zip) を解析するプログラムを作成しています。このプログラムは、私がテストしたすべての入力ファイルでうまく機能します。
それにもかかわらず、すべてのファイルで動作することを確認し、「より良いコード」を作成するために、いくつかのテスト (単体テストまたは動作テスト) を作成したいと考えています。
EPUB 仕様を実装し、いくつかの XML スニペットをテストに提供するために、これを完全に (少なくとも理論的なレベルで) 行う唯一の方法はありますか?
私は一般的なテストに精通していますが、ファイルを入力として受け取るもののテストを実装したことがないため、それについての詳細情報も探しています。:)
単体テストのアプローチは、テストにおける外部依存を排除することです。そうすれば、テストを実行するために、環境でテスト プログラムをホストする以外に何もする必要はありません。
コード内では、ほとんどの場合、「testfile.epub」には関心がないはずです。これは、OpenEpubFile() ルーチンだけの仕事です。代わりに、「ここにあるデータへのポインタがあります。どうすればそれを解凍できますか?」という特定のロジックをテストすることに関心があります。または「タイトルタグを処理するにはどうすればよいですか?」したがって、単体テストでは、解凍ロジックがどのように機能するかをテストするためのサンプルの圧縮データと、ロジックがタイトルをどのように処理するかを確認するためのサンプル タイトル タグが提供されます。適切なタイトル、非常に長いタイトル、非常に短いタイトル、不正な形式のタイトルを渡し、コードでテストする必要があるロジックを実行するために必要なさまざまな種類のデータを提示します。ただし、そのデータは毎回ファイルから取得する必要はなく、テスト ハーネスから取得することもできます。
ロジックをテストするのが難しいとわかった場合、それはおそらくそれをモジュール化する時期であることを示しています。ファイルを開くコードと、データを読み取るコードを分離する必要があります。データを解凍するコードからデータを読み取るコードを分離する必要があります。XML を解析するコードからデータを解凍するコードを分離する必要があります。画面を描画するコードから画面を構築するコードを分離する必要があります。ここでは、Rename Method と同様に、Extract Method リファクタリング プロセスが非常に役立ちます。そして、依存性反転パターンに大きく依存するようになります。
純粋なロジックを実装するステートレス コードに分割できるたびに、それらのルールだけを非常に簡単にテストできます。必要なモジュールに分割すると、既存のパターンを繰り返すことができるため、新しいケースを処理するための新しいモジュールの追加が簡単になることがわかります。
はい、ある時点で、open() ステートメントが実際にファイルを開くことができることを保証する 1 つのテストを行うことになります。単体テストされたコードがすべてのテストに合格したら、統合テストに移ります。ここで実際の .epub ファイルのセットをフィードし、出力が希望どおりであることを確認できます。
テストのためだけに .epub を再実装する必要はありません。
いくつかの小さな .epub ファイルを作成して、特定の特性を誇示し、それらに対するテストを作成します。