ユニットテストと長時間のセットアップ文字列：スタイル/ベストプラクティス

Question

ユニットテストで長時間のセットアップ文字列を使用するという意見、実践、推奨されるベストプラクティスに興味があります。

テストをインラインで、テストの近くに、またはファイルのどこかに外部化することをお勧めしますか？

私は、単体テストに固有のテスト資産について述べていますので、setup（）メソッドでの生活には必ずしも適していません。

私は両方の長所と短所を見ています - 私はできるだけテストに近いものをあなたのテストにとって重要なものにするファンですが、テスト方法では数行のストリングセットアップが素早くノーズになります。

例：ファイルから未使用のCSS宣言を削除するためのクイックパーサーを作成しています。私は特定の入力文字列を与えられたことをテストしたい、正しいテキストが削除されます。私のテストは、すべての文字列の連結で本当に騒がしくなっています。

public void removesStyleFromText() 
{ 
    StyleCleaner styleCleaner = new StyleCleaner(); 
    String source = ".presentInFileOne {\r\n" + 
      "}\r\n" + 
      "\r\n" + 
      ".presentInFileTwo {\r\n" + 
      " bottom-corners-rounded : false;\r\n" + 
      "}\r\n" + 
      ".notUsed {\r\n" + 
      "}\r\n" + 
      ""; 

    String actual = styleCleaner.removeDeclaration(source , "notUsed"); 

    String expected = ".presentInFileOne {\r\n" + 
    "}\r\n" + 
    "\r\n" + 
    ".presentInFileTwo {\r\n" + 
    " bottom-corners-rounded : false;\r\n" + 
    "}\r\n"; 

    assertEquals(expected , actual); 
} 

この例を考えると、私は外部ファイルに予想/実績を外部化できましたが、それはまた、実際の試験のために何のように少し不明瞭なテストを行います。

思考？

Answer 1

私は個人的にこのような場合に文字列をインラインに保つことを好みます。文字列はテストが何をすべきかを理解する上で重要なので、外部から見なければならないのは非生産的なようです。

文字列の種類と文字列の種類が異なるだけのテストがたくさんある場合は、その話は少し異なりますが、テーブルベースのテストソリューションを検討することもできます。あなたはmbunitを持っています。それはあなたが異なる期待された入出力で同じテストを実行できるようにするか、またはあなたがテストしたいデータのテーブルを定義することを可能にするFitnesseのようなツールを見ることができます。

Answer 2

私は文字列を外部化し、テスト対象のコメントを書きます。コメントには、これらの文字列構造よりも読みやすいという利点もあります。

Answer 3

確かに、テストしているものをすぐに伝え、再利用したいときにリファクタリングする方が簡単です。私はそれを乾燥状態に保つのが好きなので、私は通常、ビルダーや具体的なクラス（私がやっていることによる）に移動する傾向があります。これは、私が特定のテストのためにtweekできるデフォルトの設定を取得します。

Answer 4

私はそれをこのようにしましょう。そのテストでは重要で、あなたが何か「外部」にあなたのテストに頼っているのなら厳密に見られますから厳密なユニットテストではありません。

Answer 5

の適切な文字列リテラルをサポートするプログラミング言語を使用すると、問題はなくなります。例えば、Pythonは複数行の文字列をサポートしています。

source = """ 
.presentInFileOne { 
} 

.presentInFileTwo { 
     bottom-corners-rounded : false; 
} 
.notUsed { 
} 
""" 

expected = """ 
.presentInFileOne { 
} 

.presentInFileTwo { 
     bottom-corners-rounded : false; 
} 
""" 

assert removeDeclaration(source, "notUsed") == expected 

このような言語構造は、何よりも、あなたのテストは読みやすくなります。

Answer 6

multi-line Strings literals work in Javaを作るためのハックがあります。パフォーマンスは、プロダクションでは見たいとは思えませんが、テストには十分です。

私のルールは：文字列が小さい場合（< 10行）、インラインで保存しますが、いつでもすべてを切り捨てて新しいバージョンを貼り付けることができます必要に応じて、私のassertEquals（）内の文字列を変換します。

文字列リテラルが長い、複雑な場合、または（構文のハイライトなどを使用して）良いエディタを使用している場合は、テスト名のフォルダにファイル名として保存します。 JUnitテストでgetName（）を使用して文字列をロードするユーティリティ関数を使用すると、どのファイルがどのテストに属しているかを知ることができます。

これらのファイルがたくさんある場合は、テストクラス名（class.getSimpleName（））をフォルダ名として使用してグリップを維持します。