web-dev-qa-db-ja.com

ファイルリーダーをテストするにはどうすればよいですか？

いくつかのファイル形式のプロジェクトに取り組んでいます。一部の形式は.xsdsで指定されており、他の形式はそれぞれのWebサイトのドキュメントで指定されています。一部は、ドキュメントのないカスタムの社内形式です。ムワハハハハ。

問題は何ですか？

ファイルリーダーをテストしたいのですが、これを行う方法が完全にわかりません。アプリケーションの流れは次のとおりです。

file.___  ===> read by FileReader.Java ===> which creates a Model object

FileReaderインターフェースは

public interface FileReader {
    public Model read(String filename);
}

Modelには、ファイルの読み取り時に入力されるいくつかの属性があります。それは次のようになります

public class Model {
    List<String> as;
    List<String> bs;
    boolean isAPain = true;
    // ...
}

何を試しましたか？

私の唯一のアイデアは、ファイル形式ごとにファイル「ジェネレータ」を作成することでした。これらのジェネレーターは基本的にいくつかの変数（たとえば、ファイルに生成するコメントの数）を取り、サンプルファイルを出力するビルダーであり、それを読み込んで、結果のModelを以前使用した変数と比較します最初にファイルを生成します。

ただし、これにはいくつかの問題があります。

  • それが生成するファイルは、実際のファイルとは異なりますlook。ジェネレータはコンテキストをまったく認識しません。
  • 変数を手動で設定するのは私なので、Edgeケース用のジェネレーターが生成されたかどうかを認識するのは困難です。この方法は、私が12個のサンプルファイルを作成するよりもかろうじて優れています。

これを行うためのより良い方法はありますか？

編集：私が実際に意味しているので、ユニットを統合に変更しました。

EDIT2：これは私が言及したエッジのケースの例です。

各ファイルは、頂点とエッジで構成されるグラフを表します。これらの頂点とエッジはさまざまな方法で接続できるため、次のようになります。

v1 -- e1 --> v2 <-- e2 -- v3

とは違う

v1 -- e1 --> v2 -- e2 --> v3

つまり、エッジの方向が重要です。これが問題の範囲にあるかどうかはわかりませんが、頂点の数とエッジの数を手動で設定し、接続をランダムに生成するだけでは、関連するすべてのEdgeケースを考えるのは困難です。

unit-testinglanguage-agnosticintegration-testsfile-handling
19
sdasdadas

最初に、あなたの目標が何であるかについて話しましょう：

  • あなたは明らかに「ファイルフォーマット」をテストしたくない-あなたはあなたの異なるFileReader実装をテストしたい

  • 自動テストにより、できるだけ多くの異なるタイプのエラーを見つけたい

その目標を完全に達成するには、私見ではさまざまな戦略を組み合わせる必要があります。

  • まず、実際の単体テスト：FileReaderの実装は、多くの異なる部分と関数で構成されます。それぞれを個別にテストする小さなテストを作成します。ファイルからデータを実際に読み取る必要がないように関数を設計します。これらの種類のテストは、ほとんどのEdgeケースをテストするのに役立ちます。
  • 次に、生成されたファイル：これらは統合テストと呼ばれるものです。そのようなファイルは、特定のパラメーターの組み合わせ、ファイルアクセスのエラーなど、ポイント1とは異なる障害を追跡するのに役立ちます。適切なテストケースを作成するには、テストケースをグループ化するなどのいくつかの古典的な手法について学ぶことも役立ちます。等価クラスまたは境界値テスト。詳細については、 この本はGlenford Myersによる のコピーを入手してください。 ソフトウェアテストに関するWikipediaの記事 も優れたリソースです。
  • 3番目に、実際のデータを取得しようとします。これらのファイルがFileReadersによって正しく評価されていることを確認するのは難しい場合がありますが、最初の方法では明らかにされていないバグを見つけることが多いため、これを行う価値はあります。 2つの戦略。これらの種類のものを「統合テスト」とも呼ぶ人もいれば、「受け入れテスト」を好む人もいますが、実際にはこの用語は重要ではありません。

私見では、「1つの価格で」3つの戦略すべてのメリットをもたらす「ショートカット」アプローチはありません。 Edgeのケースだけでなく、標準のケースや実際のケースの障害も検出したい場合は、少なくともいくらか、より多くの場合は多くの労力を費やす必要があります。幸い、これらのアプローチはすべて、自動で繰り返し可能なテストの作成に使用できます。

それ以外に、FileReadersがそのデータを読み取るときにエラーをマスクしないことを確認する必要があります。組み込みのチェック/アサーションを作成し、内部で問題が発生したときに例外をスローします。これにより、テストコードに多くの影響を与えます。予期しない状況に対する明示的なテストファイルまたはテストケースがない場合でも、エラーを検出する可能性が高くなります。

19
Doc Brown