・assert that actual is expected(実測値が期待値であると表明する)
・例外
テストメソッドの前に以下を記述してから、例外が起きるメソッドを実行する。
@Test(expected = 例外.class)
・カスタムMatcher
・BaseMatcherクラスのサブクラスとして定義
・matchesメソッド
値の比較検証
actual(実測値)を受け取るようにする。
期待通りの動きをしている場合はtrue、そうでない場合はfalseを返す。
・describeメソッド
比較が失敗した場合に通知する情報
Descriptionオブジェクトを受け取り、
この中に検証失敗の情報を入れる。
java.lang.AssertionError:
Expected: is Descriptionオブジェクト中身
got: 実測値のtoString
appendValueメソッド
出力にダブルクォーテーションがつく
appendTextメソッド
出力にダブルクォーテーションがつかない
・コンストラクタ
expected(期待値)を受け取るようにする。
・テストのコンテキスト(テストの構造化)
・共通の初期化処
・共通の状態
●例
@RunWith(Enclosed.class)
public class クラス名Test{
public static class ○○○○{
～ テスト処理 ～
}
public static class □□□□{
～ テスト処理 ～
}
}
・パラメータ化
・テストケースを少なくし、品質も良い状態に保つには、
すべて満たしている条件と1つだけ満たしていない条件でテストを行えばよい。
●@Theory
パラメータ化テストでは@Testの代わりにこれを使う。
●@DataPoints
パラメータ化テストのパラメータ定義を行う。
●複数パラメータ化テスト
public class クラス名Test{
@DataPoints
public static Fixture[] params = {
new Fixture(1, 2, 3);
new Fixture(3, 4, 7);
new Fixture(5, 6, 11);
};
@Theory
puvli void add(Fixture p) throws Exception{
～ pがパラメータ ～
}
static class Fixture{
int x;
int y;
int expected;
Fixture(int x, int y, int expected){
this.x = x;
this.y = y;
this.expected = expected;
}
}
}
●外部リソースを使ってパラメータを定義するのが便利！
～未記載～
●assumeTrue(boolean flag)
flagがtrueの場合のみその後の検証を行う。
falseの場合はAssumptionViolatedExceptionが送出され、テストが成功となる。
●どのパラメータで失敗したかメッセージが出ないため、
assertThatの第1引数に失敗時のメッセージを記述すること。
・TDD(テスト駆動開発)
●開発工程
以下を繰り返す
・設計する
・テストコードを書く
・プロダクションコードを書く
・リファクタリングする
