単体テスト用の外部データファイル

Question

私は単体テストの初心者ですが、私はいくつかのベストプラクティスアドバイスを受けています。私はXcodeを使ってCocoaでコーディングしています。

ユーザーが入力するURLを検証する方法があります。 http：//プロトコルのみを受け入れ、有効な文字を持つURLだけを受け入れるようにしたい。

これについて1つのテストを行い、テストデータファイルを使用することは可能ですか？データファイルには、有効な/無効なURLの例と、URLが検証されるかどうかが示されます。私はまた、これを使用して、エラーメッセージの説明とドメインを確認します。

私はこの

をやっているのはなぜJUnitを用いたJavaで実用的なユニットテストを読んで、これは私は、これはOKだと思います外部データファイル、との例を示します。さらに、異なるデータをテストするために非常に似たコードで単体テストをたくさん書く必要はありません。

しかし一方で...

私はのためにテストしていた場合：

• 無効な文字
• と無効なプロトコル
• と有効なURLは、

はすべて同じテストデータファイルにあります（したがって同じテストで）、後で問題が発生しますか？私は1つのテストが1つの理由で失敗するだけであることを読んだ。

私は何をしていますか？

ユニットテストで他の人がテストデータを使用するにはどうしたらいいですか？

Answer 1

一般に、テストデータファイルは、必要なときにのみ使用してください。テストデータファイルを使用すると、いくつかの欠点があります。

• テストのコードは、テストコードとテストデータファイルに分割されています。これにより、テストを理解し維持することがより困難になります。
• できるだけ早く単体テストを保つ必要があります。データファイルを不必要に読み取るテストを行うと、テストが遅くなる可能性があります。

私は、データファイルを使用して行い、いくつかのケースがあります。

• 入力は、（例えば、XML文書）大きいです。文字列連結を使用して大きな入力を作成することもできますが、テストコードを読みにくくすることができます。
• このテストは、実際にファイルを読み取るテストコードです。この場合でも、テスト用のすべてのコードが1か所に収まるように、テンポラリディレクトリにテストファイルを書き込むことができます。

有効なURLと無効なURLをファイルにエンコードする代わりに、コードでテストを書くことをおすすめします。無効な文字のテスト、無効なプロトコルのテスト、無効なドメインのテスト、有効なURLのテストの作成をお勧めします。カバレッジが十分ではないと思われる場合は、ミニ統合テストを作成して複数の有効なURLと無効なURLをテストできます。ここでの例は、JavaとJUnitにあります：

public void testManyValidUrls() { 
    UrlValidator validator = new UrlValidator(); 
    assertValidUrl(validator, "http://foo.com"); 
    assertValidUrl(validator, "http://foo.com/home"); 
    // more asserts here 
} 

private static void assertValidUrl(UrlValidator validator, String url) { 
    assertTrue(url + " should be considered valid", validator.isValid(url); 
} 

Answer 2

私はこれを聞いて完全に合理的問題だと思いますが、私はあなたがこのことについて過度に心配する必要があるとは思いません。厳密に言えば、各テストは1つのテストのみを行うべきですが、データファイルの使用を妨げるわけではありません。

テスト中のシステム（SUT）が単純なURLパーサ/バリデータである場合、パラメータとして単一のURLが使用されると仮定します。そのため、無効なデータをどれくらい同時に入力できるかには限界があります。無効な文字と無効なプロトコルの両方を含むURLを入力した場合でも、URLが無効であるという結果が1つだけ発生します。

あなたが記述しているのは、データ駆動型テスト（パラメータ化テストとも呼ばれます）です。テスト自体を単純なものにしておくと、異なるデータを与えること自体が問題ではありません。あなたが心配する必要を行う何

は、あなたがそれは今から数ヶ月が発生した場合とき/テストが失敗した理由をすぐに見つけることができるようにしたいということです。テスト出力がデータファイルの特定の行を指している場合、何がうまくいかなかったかを素早く把握できるはずです。一方、テストが失敗し、ファイル内のいずれかの行が故障している可能性がある場合は、テストの保守性の悪夢の輪郭が見え始めるでしょう。

個人的には、できるだけテストに密接に関連するテストデータを持っていくために少し傾いています。これは、「実行可能な仕様としてのテスト」という概念を非常に重要なものとして認識しているからです。テストデータが各テスト内でハードコードされている場合、入力と期待出力の関係を非常に明確に指定することができます。テスト自体からデータを削除するほど、この「仕様」を読むのが難しくなります。

これは、各テストで入力データの値を定義する傾向があることを意味します。唯一のバリエーションが入力および/または期待出力である非常によく似たテストをたくさん書かなければならない場合は、パラメータ化されたテストを作成しますが、ハードコードされたテストからそのパラメータ化されたテストを呼び出します）。私は外部データファイルを使用したことはないと思います。

しかし、最近また私はを知りません私はConstrained Non-Determinismを使用しているので、私の入力は何ですか。代わりに、私は等価クラスとDerived Valuesで作業します。

Answer 3

をご覧ください。http://xunitpatterns.com/Data-Driven%20Test.html