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


19

私はいくつかのファイル形式のプロジェクトに取り組んでいます。一部の形式は.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を最初にファイルの生成に使用した変数と比較するビルダーです。

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

  • 生成されるファイルは、実際のファイルのようには見えません。ジェネレーターはコンテキストをまったく認識しません。
  • 私が手動で変数を設定しているので、ジェネレータがエッジケース用に生成したかどうかを認識するのは困難です。この方法は、1ダースのサンプルファイルを作成するよりもましです。

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

編集:それは私が実際に意味するものなので、ユニットを統合に変更しました。

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

各ファイルは、頂点とエッジで構成されるグラフを表します。これらの頂点とエッジはさまざまな方法でアタッチできます。

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

とは異なります

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

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


1
データ駆動型テストが思い浮かびます。実際のFileReader実装でトリガーされる可能性のあるエッジケースに基づいて、エッジケースの具体例を挙げてください。例:画像ファイル形式で見つかったエッジケースを考えると、各テーブルエントリについて、プロパティの行/列の組み合わせがサポートされている場合、その組み合わせをカバーする少なくとも1つのテストケース(データファイル)が必要です。
rwong

@rwong私は例を追加しましたが、それがあなたにアイデアを与えるかどうかはわかりません。私の問題はエッジケースの一般的な問題だと思います。見逃したことがありますか?ただし、データ駆動型テストは面白そうです。ありがとう!
sdasdadas

7
また、私はこれに気づきましたが、私のエッジケースは文字通りエッジケースです。
sdasdadas

1
テストファイルを手作業で作成して、常に同じファイルに対して実行してみませんか?
ボブソン

@Bobsonそれはジェネレータを使用するよりも少し悪いです。その場合、エッジケースを見逃す可能性があります(おそらく今は行方不明です)が、タイピングにエラーが発生する可能性もあります。また、巨大なファイルの場合、自分で作成するにはかなり時間がかかります。
sdasdadas

回答:


19

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

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

  • 自動テストでできる限り多くの種類のエラーを見つけたい

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

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

私見では、「1つの価格で」3つの戦略すべての利益をもたらす「近道」アプローチはありません。エッジケースだけでなく、標準ケースと実際のケースの障害を検出する場合は、少なくともいくつかの(おそらくはかなりの)努力を払わなければなりません。幸いなことに、これらのアプローチはすべて、自動で反復可能なテストの作成に使用できます。

それを超えて、FileReaderデータの読み取り時にエラーがマスクされないようにする必要があります。組み込みのチェック/アサーションを作成し、内部で何かがうまくいかない場合に例外をスローします。 、予期しない状況に対する明示的なテストファイルまたはテストケースがない場合でも。


すばらしい回答です。質問のタイトルを編集して、よりよく反映するようにします。ありがとう!
sdasdadas
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.