JUnitの理論メカニズム、パラメトリックテスト
3191 ワード
JUnitは4.4版から理論機構を導入し、開発者がテスト用例の設計を開始したとき、パラメータセット(理論的には無限のパラメータ)を通じて被験者を概括的に記述し、構築したパラメータセットを各caseに遍歴することで、テスト対象のカバーを実現する.簡単な例は次のとおりです.
使用上のポイントは次のとおりです.
1、runnerをTheoriesとして指定する.class
2、パラメータセットは@DataPointで注記し、かつpublic staticタイプでなければならない
3、具体的な用例は@Test注釈ではなく、@Theory注釈である
しかし、残念なことに、eclipseはJUnit理論メカニズムのサポートがよくありません.上のtestCaseのように、caseが2回目まで実行された場合、必ず失敗しますが、eclipseは失敗を示すのではなく、直接異常を投げ出し、JUnitウィンドウを通じてコードに入ると、警告ウィンドウがポップアップします.
JUnit理論メカニズムのもう一つの欠点は,データソースがハードコーディングを採用し,プロファイルを介して動的に構成できないことである.
理論メカニズムの上記の不足に鑑み、異なるデータソースの需要に対して、JUnitのパラメータ化テストを直接使用することを提案し、類似の例は以下の通りである.
使用上のポイントは次のとおりです.
1、運転runnerをParameterizedと指定する.class
2、パラメータセットは戻りタイプCollectionのコンテナに入れ、@Parametersで注記し、public staticタイプでなければならない.
3、該当するタイプの変数を宣言し、構築方法で指定したパラメータを取り戻す必要がある
4、具体的な用例は@Test注釈を使用し、かつ形容詞パラメータを入力する必要がない
5、パラメータセットは2次元配列で、1次元は全部でいくつかのパラメータ(つまりcaseが何回実行するか)を指定し、2次元は各パラメータのセットがいくつかあることを指定します(本文はboolean型の1つのパラメータしか使用していません.caseによっては複数のパラメータが必要になる場合があります).
比較的直感的に実行するだけでなく、パラメータセットはプロファイルによって動的に構成され、1つのパラメータのみを含むコードを以下のように構築できます(プロファイルが文字列であり、データ間がカンマで区切られていると仮定します).
import static org.junit.Assert.*;
import org.junit.experimental.theories.DataPoint;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;
@RunWith(Theories.class)
public class TestBoolean {
@DataPoint
public static boolean paramA = true;
@DataPoint
public static boolean paramB = false;
@Theory
public void testCase(boolean param) {
assertTrue(param);
}
}
コードで宣言された2つのパラメータparamA、paramBは、データソースとして順番にインスタンスに転送され、インスタンスはパラメータによってデータソースをフィルタします.intタイプのデータソースも宣言されている場合、booleanタイプのパラメータのみが受け入れられるため、testCaseには転送されません.testCaseが複数のデータソースを使用する必要がある場合、testCase(boolean parama,boolean paramb)のようにパラメータリストに拡張できます.paramA、paramBはtestCaseに渡されます.つまり、4つの組み合わせがあります.もちろん、異なるタイプのパラメータに設定することもできます. 使用上のポイントは次のとおりです.
1、runnerをTheoriesとして指定する.class
2、パラメータセットは@DataPointで注記し、かつpublic staticタイプでなければならない
3、具体的な用例は@Test注釈ではなく、@Theory注釈である
しかし、残念なことに、eclipseはJUnit理論メカニズムのサポートがよくありません.上のtestCaseのように、caseが2回目まで実行された場合、必ず失敗しますが、eclipseは失敗を示すのではなく、直接異常を投げ出し、JUnitウィンドウを通じてコードに入ると、警告ウィンドウがポップアップします.
JUnit理論メカニズムのもう一つの欠点は,データソースがハードコーディングを採用し,プロファイルを介して動的に構成できないことである.
理論メカニズムの上記の不足に鑑み、異なるデータソースの需要に対して、JUnitのパラメータ化テストを直接使用することを提案し、類似の例は以下の通りである.
import static org.junit.Assert.*;
import java.util.Arrays;
import java.util.Collection;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
@RunWith(Parameterized.class)
public class TestBoolean {
private boolean param;
@SuppressWarnings("rawtypes")
@Parameters
public static Collection data() {
return Arrays.asList(new Object[][] { { true },
{ false } });
}
public TestBoolean(boolean param) {
this.param = param;
}
@Test
public void testCase() {
assertTrue(param);
}
}
は理論的機構と同様に、パラメトリックテストはデータソースを静的コンテナに入れ、コンテナにはいくつかのパラメータのセットがあり、使用例は数回実行され、毎回異なるパラメータで実行される.使用例が失敗した場合も、JUnitウィンドウで直接位置を特定できる詳細な失敗情報が表示されます.使用上のポイントは次のとおりです.
1、運転runnerをParameterizedと指定する.class
2、パラメータセットは戻りタイプCollectionのコンテナに入れ、@Parametersで注記し、public staticタイプでなければならない.
3、該当するタイプの変数を宣言し、構築方法で指定したパラメータを取り戻す必要がある
4、具体的な用例は@Test注釈を使用し、かつ形容詞パラメータを入力する必要がない
5、パラメータセットは2次元配列で、1次元は全部でいくつかのパラメータ(つまりcaseが何回実行するか)を指定し、2次元は各パラメータのセットがいくつかあることを指定します(本文はboolean型の1つのパラメータしか使用していません.caseによっては複数のパラメータが必要になる場合があります).
比較的直感的に実行するだけでなく、パラメータセットはプロファイルによって動的に構成され、1つのパラメータのみを含むコードを以下のように構築できます(プロファイルが文字列であり、データ間がカンマで区切られていると仮定します).
@Parameters
public static Collection data() {
String strTemp = property.getValue("params");
String[] arrayTemp = strTemp.split("\\,");
if (arrayTemp.length > 0) {
List arrayList = Arrays.asList(arrayTemp);
Object[][] tt = new Object[arrayList.size()][1];
for (int i = 0; i < arrayList.size(); i++) {
tt[i][0] = arrayList.get(i);
}
return Arrays.asList(tt);
} else {
fail("params in configure file is null!");
return null;
}
}