Junit 4 Test詳細

8360 ワード

[TOC]

紹介する

Junit 4はJunit 3に基づいて改良されたユニットテストフレームワークである

junit 4 TestCase

を継承する必要はありません

試験方法の命名には特定の要求はなく、測定対象方法の前に@Testを加えれば

である.

は@befroeによって@setUpの方法を置き換え、@Afterによって@tearDownの方法を置き換えた.

1つのテストクラスでは、複数の@Beforeを使用して複数のメソッドを注釈することもできます.これらのメソッドは、各テストの前に実行されます.@Beforeは、各テストメソッドの実行前に1回初期化されます.同様に、@Afterは、各テストメソッドの実行が完了した後に1回実行されます.つまり、この2つの注釈の初期化とログアウトによって、各テストメソッド間の独立性が互いに干渉しないことを保証することができます.その欠点は効率が低いことです

@BeforeClassと@AfterClass

を追加
この2つの注釈を使用する方法では、各方法で1回ずつ実行するのではなく、この2つの注釈を使用して、@Before@Afterの実行効率の低い問題を減らすことができます.

新しいテストタイプ

異常試験@Test(expected=*.class)およびタイムアウト試験@Test(timeout=xxx)

新規断言方法

配列データを比較するための新しいassertメソッドassertEquals(Object[] expected, Object[] actual)

テストケース作成上の注意事項

試験方法@Test注記を用いる修飾

を行う必要がある.

試験方法はpublic void ，

を使用しなければならない.

試験ユニットの各方法 ，

新しいソースディレクトリは、テストコード

を格納するために使用される.

テストクラスTestをクラス名の接尾辞として使用(必要でない)

試験方法testを方法名のプレフィックスとして使用する(必要でない)

できるだけassertキーワードを使用してエラー(必要でない)

を断言する.

テスト分析の原則

Failureは一般的にユニットテストで使用する断言方法の判断に失敗したことによるものであり、予想結果とプログラム実行結果が一致しないことを示している

Errorはコード異常によるものであり、テストコード自体に生じるBug

である.

試験例 ，

テストプロセス

  @BeforeClass
  public static void setUpBeforeClass() throws Exception {
  }

  @AfterClass
  public static void setUpAfterClass() throws Exception {
  }



  @Before
  public void before() throws Exception {
  }



  @After
  public void after() throws Exception {
  }

@BeforeClass修飾メソッドは、すべてのメソッドのロード前に実行され、クラスのロード後に静的に実行され、 ，

で実行する.

@AfterClassで修飾する方法は、すべての方法の実行が完了した後に実行され、通常、データベース接続

を閉じるなどのリソースクリーンアップを行うために使用される.

@Beforeおよび@Afterは、

にある.

JUnit注釈活用

@Test(excepted=XX.class)運転時にある異常を無視する

@Test(timeout=[ms])プログラムの実行を許可する時間単位ミリ秒

@Ignoreで修飾する方法は、テスタによって無視される

である.

@RunWith試験運転器org.junit.runner.Runne

を修正することができる.

ユニットテストの実行順序

デフォルトでは、ユニットテストは無秩序であり、ユニットテストフレームワークの出発点はであり、すなわち、各ユニット間では互いに影響を及ぼさないため、ユニットテストの実行順序を設定することは意味がない.
ただし、特殊なプロセスにかかわる場合や、テストの実行順序を自分の制御の下にしなければならない場合も可能です.

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class TempTest {
}

@FixMethodOrder Junit 4.11に追加された指定試験方法の実行順序の特性は、サポート順序が3種類あり、ここでは名前順に並べ替えられています

デフォルト(MethodSorters.DEFAULT)

デフォルトの順序はメソッド名hashcode値によって決定され、hash値のサイズが一致する場合、名前の辞書順に決定されます.hashcodeの生成はオペレーティングシステムに関連するため、異なるオペレーティングシステムでは異なる実行順序が発生する可能性があります.あるオペレーティングシステムでは、複数回実行される順序は変わりません.
ソート方法

    /**
     * DEFAULT sort order
     * @type {Comparator}
     */
    public static Comparator DEFAULT = new Comparator() {
        public int compare(Method m1, Method m2) {
            int i1 = m1.getName().hashCode();
            int i2 = m2.getName().hashCode();
            if (i1 != i2) {
                return i1 < i2 ? -1 : 1;
            }
            return NAME_ASCENDING.compare(m1, m2);
        }
    };

メソッド名別(MethodSorters.NAME_ASCENDING)

メソッド名によるソートは、文字の辞書順であるため、このように指定した実行順序は常に一致します.
テストメソッドには、テストメソッドがtest_であるなどの名前付きルールが必要です.nnnの先頭、nnnは000-999の数字を表します
ソート方法

    /**
     * Method name ascending lexicographic sort order, with {@link Method#toString()} as a tiebreaker
     * @type {Comparator}
     */
    public static Comparator NAME_ASCENDING = new Comparator() {
        public int compare(Method m1, Method m2) {
            final int comparison = m1.getName().compareTo(m2.getName());
            if (comparison != 0) {
                return comparison;
            }
            return m1.toString().compareTo(m2.toString());
        }
    };

JVM（MethodSorters.JVM）

JVMから返されるメソッド名の順に実行されます.このようにして、テストメソッドの実行順序は予測できません.つまり、です.
なお、JVMが返すメソッド名は、異なるjdkで一致しない場合がありますが、1.7以降のjdkで返す順序は異なるに違いありません.

Junit 4試験方法手順原理

実際にJunitでは、あるJunit内のすべてのテストメソッドを反射メカニズムで取得し、メソッドの配列を生成し、配列内のこれらのテストメソッドを順次実行します.実行順序をannotationで指定すると、Junitはテストメソッドの配列を取得した後、指定した順序に従って配列内のメソッドをソートします.

    public static Method[] getDeclaredMethods(Class> clazz) {
        Comparator comparator = getSorter(clazz.getAnnotation(FixMethodOrder.class)); // 
        Method[] methods = clazz.getDeclaredMethods();
        if (comparator != null) {
            Arrays.sort(methods, comparator); // 
        }
        return methods;
    }

定義された順序は

package org.junit.runners;

/**
 * Sort the methods into a specified execution order.
 * Defines common {@link MethodSorter} implementations.
 *
 * @since 4.11
 */
public enum MethodSorters {
    /**
     * Sorts the test methods by the method name, in lexicographic order,
     * with {@link Method#toString()} used as a tiebreaker
     */
    NAME_ASCENDING(MethodSorter.NAME_ASCENDING),

    /**
     * Leaves the test methods in the order returned by the JVM.
     * Note that the order from the JVM may vary from run to run
     */
    JVM(null),

    /**
     * Sorts the test methods in a deterministic, but not predictable, order
     */
    DEFAULT(MethodSorter.DEFAULT);
}

MethodSortersに設定するとJVMの場合、Comparatorの実装は1つも提供されていないため、実行方法の順序は実際にはclazz.getDeclaredMethods();で得られた配列内の方法の順序であり、javaでgetDeclaredMethodsに返される方法には順序が指定されていないため、最終的にJunitテスト方法の実行順序も確定していない

テストキット

テストスイートは、テストクラスを組織して実行するテストクラスです.

@RunWith(Suite.class)
@Suite.SuiteClasses({UserTest1,UserTest2,UserTest3})
public class SuiteTest{
}

テストキットの注意事項

，

テスターSuiteを変更します.class

実行するテストクラスをSuiteに入れる.SuiteClasses({})の配列のうち

パラメトリック設定

テストが必要なのはテストデータだけで、コード構造は変わらず、テストパラメータを変更するだけです.

@RunWith(Parameterized.class)
public class ParameterTest {

    int expected = 0;
    int input1 = 0;
    int input2 = 0;

    @Parameters
    public static Collection

コードプロセスは

デフォルトのテストランナを@RunWith(Parameterized.class)

に変更

は、の例のexpected input 1 input 2

を格納する変数を宣言する.

は、Collection ， @Parameters の戻り値

を宣言する.

は、テストクラスにパラメータを有する共通構造関数ParameterTestを宣言し、変数に

を付与する.

ユニットテスト統計と評価

ユニットテストコードオーバーライドの説明

まず、コードオーバーライドはユニットテストに属し、統合テストは計算されません.
被測定プログラムの論理を理解する必要があり、各関数の入出力、論理分岐コードの実行状況を考慮する必要がある.このとき、私たちのテスト実行状況はコードオーバーライド率で測定され、ホワイトボックスオーバーライドと理解できる.
ここではjavaコードの上書き分類について説明します

行の上書き率:測定対象プログラムの各行のコードが実行するか否かを測定し、標準行の少なくとも1つの命令が

を実行するか否かを判断する.

クラスオーバーライド率:classクラスファイルが

実行されるかどうかをメトリック計算する.

分岐オーバーライド率:ifとswitch文の分岐オーバーライドを測定し、1つの方法の合計分岐数を計算し、実行と非実行の分岐数

を決定する.

メソッドのオーバーライド率:測定プログラムのメソッドの実行状況を測定し、実行するかどうかは、メソッドの少なくとも1つの命令が

実行されているかどうかに依存する.

命令オーバーライド:カウントユニットは単一javaバイナリコード命令であり、命令オーバーライド率はコードが実行するかどうかの情報を提供し、メトリックは完全に独立したソースコードフォーマット

である.

ループ複雑度:(線形)組合せにおいて、1つの方法におけるすべての可能な経路の最小数を計算し、欠落した複雑度は同様に試験例がこのモジュール

に完全にカバーされていないことを示す.

JAvaコードオーバーライド試験方法

コードがバイナリを生成する時使用するASM技術はバイトコードの方法を修正して、Jarファイル、classファイルのバイトコードのファイルを修正することができて、ソースコードを注入して、注入の過程は杭を挿して、それからテストの用例を実行して、統計は呼び出すかどうか

現在javaで使用されているUATと自動統計オーバーライドテストの技術

maven自動構築チェーンhttp://maven.apache.org/内http://maven.apache.org/plugins/index.htmlJunit拡張プラグイン

あり

gradle自動構築チェーンhttps://gradle.org/内https://plugins.gradle.org/search?term=junit拡張プラグイン

mockito注入ユニット試験http://site.mockito.org/

jacocoカバー率統計http://www.eclemma.org/jacoco/

scikit-learnでテストデータセットを生成する

プログラマ必須:文字列ハッシュ関数の比較