Spring 5でSpring Testのここが変わる_公開版

© 2018 NTT DATA Corporation
2018/10/31
株式会社NTTデータ生産技術部ソフトウェア工学推進センタ
平栗勇人
Spring 5でSpring Testのここが変わる

© 2018 NTT DATA Corporation 2
平栗勇人
株式会社NTTデータ
技術革新統括本部
システム技術本部生産技術部
ソフトウェア工学推進センタ
TERASOLUNA FWチーム
Server FWの開発リーダー

TERASOLUNAフレームワークのコンセプト
Spring
Security
Spring
MVC
JPA
MyBatis
1.OSSを組み合わせ、
独自実装部分を極小化
2.OSSの機能を最大限に
活かして開発するための
ベストプラクティスを提供
開発ガイドライン
http://terasolunaorg.github.io/
基盤としてSpringを採用している

はじめに

そもそも

なぜ、
テストを行うのか？

仕様通りに
動くことを
確認するため

どんなに優秀な
人間でもミスをする。
ミスをしない人間は、何もしない人間だけだ。
(The only man who never makes mistakes is
the man who never does anything.)
-- Theodore Roosevelt

自分の作成した
コードに責任を持ち、

安心して開発を
続けるために
テストは不可欠。

コーディングすれば
もれなく付きまとう
作業なので、

テストの効率性は、
生産性に直結。

Springは
テストしやすいの？

本日は、
それについてお話しします。

 Springとテスト
 クラスやメソッド単位でのテスト
 クラス同士を組み合わせたテスト
 Spring 5での変更点
 JUnit 5のサポート
 テスト並行実行のサポート
 その他の改善
 まとめ

 まとめ

大規模な
アプリケーションでは、

バグを発見する
タイミングが
遅ければ遅いほど、

影響範囲は
大きくなる。

なので、

いかに早くバグを
発見できるかが重要。

バグを早期発見
するためには、

クラスやメソッドといった小さな
単位でテストすることが大切。
クラス A
依存
依存
クラス B
クラス C
メソッド1
メソッド2
JUnit
テスト
メソッド1
メソッド2
メソッド1
メソッド2
JUnit
テスト
JUnit
テスト

また、作成したらすぐにモックを
使ってテストできるのが理想。
クラス A
依存
依存
モック
クラス B
モック
クラス C
JUnit
テスト
メソッド1
メソッド2

しかし、疎結合を
意識しないと、

クラス単体で
試験すること自体が
難しくなる。

悪い例

public class A {
public String foo() {
B objB = new B();
// objB.doSomething()
// 処理結果に応じてreturn
}
}
A#foo()は、B#doSomething()の
処理結果に応じて”成功”、”失敗”を返す。

public class A {
B objB = new B();
// objB.doSomething()
// 処理結果に応じてreturn
}
}
いま、クラスA単体の挙動をテストしたい。

A#foo()の戻り値が”失敗”であることを確
認するテストメソッドAを作成する。
class ATest {
@Test
void fooの戻り値が「失敗」であること() {
A objA = new A();
assertEquals(“失敗", objA.foo());
}
}

A#foo()内でBをnewしているため、
テスト実行時にBも実行する必要がある。
class ATest {
@Test
A objA = new A();
}
}
B objB = new B();

そして、このテストケースを通すためには、
class ATest {
@Test
A objA = new A();
}
}
B objB = new B();

B#doSomething()の処理を失敗させる
必要があり、初期化が煩雑になる。
class ATest {
@Test
A objA = new A();
}
}
B objB = new B();

そもそもクラス単体での試験に
なっていない。。。
class ATest {
@Test
A objA = new A();
}
}
B objB = new B();

メソッド内でnew
するだけで、疎結合
ではなくなってしまい、

単体テストの実施
そのものが難しくなる。

疎結合にする一つの
デザインパターンとして、
DIがある。

Springは、
フレームワークの
最重要機能として、

DIを自動で行い、
インスタンスを
組み立ててくれる基盤、

DIコンテナ
を
提供している。

クラス A
クラス Bの生成
クラス B
DIコンテナ
クラス A
利用
Bの実装クラス
クラス Aはクラス Bのインスタンスを直接生成している
Bのインタ
フェース
生成
通常のJava
SpringのDI
注入
DIコンテナがクラス Bのインスタンスを生成・注入している
クラス B
B objB = new B();

このように、

クラス間が疎結合
になるので、

クラス A
Bの実装クラス
Bのインタ
フェース
クラス B
モック
クラス B
依存クラスをモックに差し替えること
が可能になる。
差し替え可能

クラス A
Bの実装クラス
Bのインタ
フェース
クラス B
モック
クラス B
よって、クラス単体でのテストが可能
になる！
JUnit
テスト

クラス A
Bの実装クラス
Bのインタ
フェース
クラス B
モック
クラス B
モックテストは、Mockitoなどのモック
ライブラリを使うことが多い。
JUnit
テスト

 まとめ

次に、単体テストを終えたクラス
同士を組み合わせてテストする
時を考えてみる。
クラス A
依存
依存
クラス B
モック
クラス C
JUnit
テスト

インスタンスの生成や依存性の
解決はDIコンテナが担っている
ので、
DIコンテナ
クラス A
利用
Bの実装クラス
Bのインタ
フェース
生成注入
クラス B

クラスBに依存するクラスAのテ
ストをするには、DIコンテナが必
要となる。しかし…、
DIコンテナ
クラス A
利用
Bの実装クラス
Bのインタ
フェース
生成注入
クラス B

JUnitなどのテスティングフレー
ムワーク上でDIコンテナを動か
すのは難しい…。
DIコンテナ
クラス A
利用
Bの実装クラス
Bのインタ
フェース
生成注入
クラス B
JUnit
テスト

しかし！

Springは、
結合テストを支援
するモジュールとして

Spring Test
を
提供している。

Spring Testに
含まれる

Spring
TestContext
Framework(TCF)
を用いると、

JUnitやTestNG
などのテスティング
フレームワーク上で

DIコンテナ
を動かせる！

クラス A
利用
注入
クラスA, BがDIコンテナ上で正しく動作するか
テストしたい。
生成
DIコンテナ
Bの実装クラス
Bのインタフェース
クラス B

はじめに、pom.xmlにspring-testの
ライブラリを追加する。
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<scope>test</scope>
</dependency>

次に、テストクラスでTestContext Framework
(TCF)を使うよう指定する。※詳細はのちほど
TestContext Framework
クラス A
利用
テストクラス A
Bの実装クラス
Bのインタ
フェース
クラス B
1. TCFを使うよ！

また、TCF上にDIコンテナを作成するためのBean
定義ファイルを指定する。
DIコンテナ
クラス A
利用
Bの実装クラス
Bのインタ
フェース
クラス B
2. このBean定義ファ
イルをもとにDIコン
テナを作成して！

注入
以上の簡単な設定で、テスティングフレームワーク上
でDIコンテナと連携したテストが可能になる！
生成
クラス A
利用
Bの実装クラス
Bのインタ
フェース
クラス B
DIコンテナ注入生成
2. このBean定義ファ
イルをもとにDIコン
テナを作成して！

では、

Spring 5で何が
変わったのだろうか

 まとめ
目玉の改善！

Spring 5のSpring Testでは、
これからお話しする
JUnit 5のメリットを

すべて享受すること
ができます！

 まとめ
・ JUnitの説明
・ JUnit 5の概要
・ JUnit 5のイケてるところ
・ TCFとの連携方法

JUnitは、以下を提供している。
・テストケースのフォーマット
・テストの実行基盤
・テストの期待値と実測値の検証API
JUnitの説明

簡単に言うと、
・テストケースのフォーマット
⇒どのようにテストを書いて、
・テストの実行基盤
⇒どのように実行し、
・テストの期待値と実測値の検証API
⇒どのように検証するか
JUnitの説明

 まとめ
・ JUnitの説明

2017年、
JUnit 5の概要

JUnit 5が
リリースされました。
JUnit 5の概要

実に10年ぶりの
メジャーアップデート
JUnit 5の概要

JUnit 5は、
3つのサブプロジェクトで
構成される。
JUnit 5 = Platform + Jupiter + Vintage
JUnit 5の概要

JUnit 5の概要
Eclipse, STS, IntelliJ IDEA, Maven, Gradle etc.
JUnit Platform
JUnit Vintage JUnit Jupiter
3rd party
JUnit 3,4の
テスト
JUnit 5の
テスト
その他の
テスト
共通的な実行エンジン
実行API
JUnit3, 4
実行エンジン
実装
API
JUnit 5
実行エンジン

JUnit 5=
JUnit Platform +
JUnit Jupiter +
JUnit Vintage
用途や環境に合わせて適切な
ライブラリを取り込む。
JUnit 5の概要

サポートされる
Javaのバージョンは、
Java 8 以上
JUnit 5の概要

 まとめ
・ JUnitの説明

JUnit 5はどこが
イケてるの？
JUnit 5のイケてるところ

・ネストしたテスト
・パラメータ化テスト
・アサーションAPIの強化
・条件付きテスト

これからお話しするJUnit 5
のAPIの中には、一部実験
的なものも含まれます。

網羅的にテストしようと
すると、テストメソッドは
増えますよね？
JUnit 5のイケてるところ: ネストしたテスト

大量のテストメソッドが
並列に
実装されていると、

テストコードを見たときに
各テストケースの意図を
読み解くのが難しくなる。

JUnit 4
～並列で書いたとき～
@Before
public void setUp() {
// リストの初期化（0件）
}
@Test
public void sizeメソッドの確認_リストが初期状態() {
// 0が返されることの確認
}
@Test
public void sizeメソッドの確認_リストが1件() {
// リストに1件追加
// 1が返されることの確認
}
@Test
public void isEmptyメソッドの確認_リストが初期状態() {
// trueが返されることの確認
}
@Test
public void isEmptyメソッドの確認_リストが1件() {
// リストに1件追加
// falseが返されることの確認
}
各テストケースの観点が
読み取りずらくなる
同じような初期化処理
が重複する
同じような初期化処理
が重複する

解決するためには、

テストメソッドを何らか
の基準でグループ化
する必要がある。

JUnit 実践入門
によると、

「テストケースは共通の
初期化処理をもつもの
でグループ化すべき」

とあります。

JUnit 4では、

@RunWith(Enclosed.class)
を利用して
次のように書けた。

JUnit 4
～グループ化～
public class ListTestEnclosedExmaple {
public static class リストが初期状態 {
@Before
public void setUp() {} //リストの初期化（0件）
@Test
public void sizeメソッドの確認() {}
@Test
public void isEmptyメソッドの確認() {}
}
public static class リストが1件 {
@Before
public void setUp() {} //リストの初期化後、1件追加
@Test
@Test
}
}
アウタークラスに
@RunWith
(Enclosed.class)
を付与する。

JUnit 4
～グループ化～
@Before
@Test
@Test
}
@Before
public void setUp() {} //リストの初期化後、1件追加
@Test
@Test
}
}
staticインナークラスで、
同じ初期化処理が必要な
テストケースをグループ化。
staticインナークラスで、
同じ初期化処理が必要な
テストケースをグループ化。

staticなので、
アウタークラスのメンバに
アクセスできない。

@Before
@Test
@Test
}
@Before
public void setUp() {} //リストに1件追加
@Test
@Test
}
}
このように、全体的な初期
化処理をアウタークラスに
書けばもっとスッキリしそう
だけど、制約上できない。
JUnit 4
～仕様上の制約～

JUnit 5では
そのような実装が
可能になる！

JUnit 5の新API
@Nested
を使うと、
※@RunWith(Enclosed.class)は廃止。

JUnit 5
～ネスト化～
class ListTestNestedExample {
@BeforeEach
void setUp() {} //リストの初期化（0件）
@Nested
class リストが初期状態 {
@Test
void sizeメソッドの確認() {}
@Test
void isEmptyメソッドの確認() {}
}
@Nested
class リストが1件 {
@BeforeEach
void setUp() {} //リストに1件追加
@Test
@Test
}
}
非staticインナークラスに
@Nestedアノテーションを付
与し、同じ初期化処理が必
要なテストケースをグループ化
(深さ1でネスト化)。

JUnit 5
～ネスト化～
@BeforeEach
@Nested
@Test
@Test
}
@Nested
@BeforeEach
@Test
@Test
}
}
Tips: JUnit 5の変更点
①public修飾子が省略可
能
Tips: JUnit 5の変更点①
クラスやメソッドのpublic修飾子
が省略可能になった。

JUnit 5
～ネスト化～
@BeforeEach
@Nested
@Test
@Test
}
@Nested
@BeforeEach
@Test
@Test
}
}
Tips: JUnit 5の変更点②
前処理/後処理アノテーションが変
わった。
@Before/After
⇒@BeforeEach/AfterEach
@BeforeClass/AfterClass
⇒@BeforeAll/AfterAll

@Nested
class A{
@Nested
class B{
@Nested
class C{
}
}
}
JUnit 5
～ネスト化～
ネストはいくらでも深くすることができ、
継承関係を保ったままテストケース
を構造化できる！

テストケースが
大量になった場合、
JUnit 5のイケてるところ: パラメータ化テスト

初期化処理ごとに
テストメソッドをグループ化
するだけではなく、

引数のバリエーション
テストを一つのテスト
メソッドで書けると、

もっと見通しが良くなる。

JUnit 4では、

@RunWith(Theories.class)
を利用して
それが実現できた。

JUnit 4
～パラメータ化していない例～
public class NonParameterizedExample {
//ageCheckメソッドに未成年の年齢を渡したときのテスト
@Test
public void ageCheckメソッド_0歳() {}
@Test
public void ageCheckメソッドの確認_10歳() {}
@Test
public void ageCheckメソッドの確認_19歳() {}
}
入力値のバリエーションテス
トをメソッドごとに書いている。

JUnit 4
～パラメータ化後～
public class ParameterizedExample {
@DataPoints("child")
public static int[] VALUES_CHILD = { 0, 10, 19 };
@Theory
public void ageCheckメソッドの確認_未成年(
@FromDataPoints("child") int age) {}
}
アウタークラスに
を付与する。

JUnit 4
@Theory
}
テスト対象メソッドの戻り値が同値なテス
トケースをひとまとめにし、引数をもつテス
トメソッドを作成する。(パラメータ化)
メソッドには@Theoryを付与する。

JUnit 4
@Theory
}
入力パラメータは、staticな変数に
@DataPointsを付与して定義する。

JUnit 5では
さらに簡潔に、
高機能になった！

JUnit 5の新API
@ParameterizedTest
を使うと、
※@RunWith(Theories.class)は廃止。

class ParameterizedExampleJunit5 {
@ParameterizedTest
@ValueSource(ints = { 0, 10, 19 })
void ageCheckメソッドの確認_未成年(int age) {}
}
パラメータ化したいテストメソッドに
@ParameterizedTestを付与する。
JUnit 5
～パラメータ化～

class ParameterizedExampleJunit5 {
@ParameterizedTest
@ValueSource(ints = { 0, 10, 19 })
void ageCheckメソッドの確認_未成年(int age) {}
}
入力パラメータは、テストメソッドに付
与した@ValueSourceで定義する。
JUnit 5

Double, int, long,
String変数を指定
@ValueSource(double[], int[], long[],
String[])
Enum定数を指定 @EnumSource(Enumクラス)
Streamや配列を返
すメソッドを指定
@MethodSource(“メソッド名”)
CSV形式で値を指定 @CsvSource({“x1,y1”, “x2,y2”})
CSVファイルを指定 @CsvFileSource(resources=“CSVファイル名”)
JUnit 5
Tips:
以下のようなパラメータ定義アノテー
ションが提供されている。

パラメータ化テストのAPIは、
2018/10/31現在、実験的
なAPIとして提供されている。

アサーションに関しても
進化した！
JUnit 5のイケてるところ: アサーションAPIの強化

新しいAPIの追加
・assertAll()
・assertThrows()
・assertTimeout() など

JUnit 5
～assertAll()～
バグを仕込んだPersonクラス
public class Person {
public String getFirstName() {
return "";
}
public String getLastName() {
return "Hirakuri";
}
public String getAge() {
return "";
}
}
“Yuto”を返したい。
“29”を返したい。

@Test
void person情報が正しく取得できているか確認() {
assertEquals("Yuto", person.getFirstName());
assertEquals("Hirakuri", person.getLastName());
assertEquals("29", person.getAge());
}
JUnit 5
～assertAll()～
今まで

一番最初のアサーションで失敗すると、
以後のアサーションが実行されない。
JUnit 5
～assertAll()～

JUnit 5
～assertAll()～
assertAll()使用
@Test
void person情報が正しく取得できているか確認_All() {
assertAll(
() -> assertEquals(“Yuto”, person.getFirstName()),
() -> assertEquals(“Hirakuri”, person.getLastName()),
() -> assertEquals("29", person.getAge())
);
}

JUnit 5
～assertAll()～
一番最初のアサーションで失敗しても、
最後のアサーションまで実行される！

public class Calculator {
public String divide(String a, String b) {
return String.valueOf(Integer.parseInt(a)
/ Integer.parseInt(b));
}
}
JUnit 5
～assertThrows()～
割り算をするdivideメソッド

今まで
@Test(expected = ArithmeticException.class)
public void ゼロ除算時に算術例外の発生確認() {
calc.divide("5", "0");
}
@Testのexpected
属性に例外クラスを指
定して確認していた。
JUnit 5

assertThrows()使用
@Test
void ゼロ除算時に算術例外の発生確認() {
assertThrows(ArithmeticException.class,
() -> calc.divide("5", "0"));
}
メソッド内で自然なスタ
イルで書ける。
JUnit 5

今まで
JUnit 5
@Test
public void ゼロ除算時の算術例外メッセージ確認() {
try {
calc.divide("5", "0");
fail();
} catch (ArithmeticException e) {
assertEquals("/ by zero", e.getMessage());
}
}
例外メッセージを確認す
るときは、try-catchを
使って書いていた。

assertThrows()使用
JUnit 5
@Test
void ゼロ除算時の算術例外メッセージ確認() {
Throwable e = assertThrows(
ArithmeticException.class,
() -> calc.divide("5", "0"));
assertEquals("/ by zero", e.getMessage());
}
Throwableオブジェクト
を返すので、try-catch
を使わずに書ける！

assertThat()がJUnitライブラリから
削除されました。
背景: JUnit 5から「Matcherは、ユーザが自由に選んでね」
というスタンスをとっているため、HamcrestのMatcher依存
であったassertThat()も切り離された。
https://github.com/junit-team/junit5/wiki/OLD-Assertion-API#reasons-not-to-introduce-yet-another-assertion-apilibrary
⇒JUnit 5でassertThat()を使いたい場合は、
Hamcrestライブラリを使えばOK！
補足

あるテストケースを
一時的に無効にしたい時、
JUnit 5のイケてるところ: 条件付きテスト

JUnit 4
@Ignore
JUnit 5
@Disabled

JUnit 5は
それだけではない。

条件に応じて
有効/無効にできる！

JUnit 5
～条件付きテスト実行～
class OSExmaple {
@Test
@EnabledOnOs({ OS.WINDOWS })
@EnabledOnJre({ JRE.JAVA_8, JRE.JAVA_9 })
void windowsかつJREバージョンが8か9でのみ実行() {}
}
実行環境ごとにテストケースを
有効/無効にできる！

OSを条件に有効/無効 @EnabledOnOs(OS.WINDOWS)
@DisabledOnOs({OS.LINUX, OS.MAC})
Java実行環境を条件に
有効/無効
@EnabledOnJre(JRE.JAVA_8)
@DisabledOnJre({JRE.JAVA_9, JRE.JAVA_10})
JVMシステムプロパティを条
件に有効/無効
@EnabledIfSystemProperty(named = "os.arch",
matches = ".*64.*")
@DisabledIfSystemProperty(named = "ci-server",
matches = "true")
環境変数を条件に有効/
無効
@EnabledIfEnvironmentVariable(named = "ENV",
matches = "staging-server")
@DisabledIfEnvironmentVariable(named = "ENV",
matches = ".*development.*")
JUnit 5
～条件付きテスト実行～

そんなイケてる
JUnit 5ですが、

Spring TestContext
Framework
と連携するにあたっては

ドラスティックな
仕様変更がありました。

JUnitの拡張方法が一本化
Runner
(@RunWith)
Rule
(@Rule)
ClassRule
(@ClassRule)
Extension
(@ExtendWith)
JUnit 4 JUnit 5

今までは、JUnit上でSpring TestContext
Frameworkを動作させるために、Runnerを使
用していた。
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = AppConfig.class)
public class ABIntegrationTestJUnit4 {
}
Spring Testから提供されている
SpringJUnit4ClassRunnerを
@RunWithで指定。

JUnit 5からは同様の
手段が取れなくなって
しまいましたが、

Spring 5の
Spring Testでは、
仕様変更に追従！

JUnit 5が提供している
Extensionを利用して、

JUnit 5上で
TCFを動かすための
サポートクラスを提供！

 まとめ
・ JUnitの説明

JUnit 5上でSpring TestContext Framework
を動かすための設定方法（ベーシックな方法）
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.context.ContextConfiguration;
import org.springframework.test.context.junit.jupiter.SpringExtension;
@ExtendWith(SpringExtension.class)
class ABIntegrationTest {
}
@ExtendWithのvalue属性
に、JUnit 5上でTCFを動かす
ためのExtensionクラスを指定
する。

を動かすための設定方法（ベーシックな方法）
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.context.ContextConfiguration;
import org.springframework.test.context.junit.jupiter.SpringExtension;
@ExtendWith(SpringExtension.class)
}
@ContextConfigurationの
classes属性に、DIコンテナを
作成する際のBean定義ファイ
ルを指定する。

import org.springframework.test.context.junit.jupiter.SpringJUnitConfig;
@SpringJUnitConfig(classes = AppConfig.class)
} @SpringJUnitConfig =
@ExtendWith(SpringExtension.class)+
@ContextConfiguration
Tip:
Webアプリ向けのDIコンテナを作成する、@SpringJUnitWebConfigも提供されている。
(@SpringJUnitWebConfig=@SpringJUnitConfig + @WebApplicationConfig)
を動かすための設定方法（@SpringJUnitConfig）

JUnit 5には実験的なAPI
が数多く存在するので、
使用の際は注意。
https://junit.org/junit5/docs/current/user-guide/#api-evolution-experimental-apis

 まとめ

JUnit 4.7/5.3以降、
テストの並行実行が
可能になったが、
Spring 5変更点：テスト並行実行のサポート

Spring 4では、
TCFを使用したテストは
並行実行できなかった。

Spring 5からは、
TCFを使用したテストも
並行実行が可能になった！

MavenでJUnit 5テストの並行実行をする設定例
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.0</version>
<configuration>
<properties>
<configurationParameters>
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.config.strategy=fixed
junit.jupiter.execution.parallel.config.fixed.parallelism=20
</configurationParameters>
</properties>
<reportFormat>plain</reportFormat>
</configuration>
<dependencies>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-surefire-provider</artifactId>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
</dependency>
</dependencies>
</plugin>
maven-surefire-pluginの
configurationParametersに以下を設定
・enabled=true (有効)
・parallelism=20 (同時スレッド数)
・strategy=fixed (スレッド数固定)

MavenでJUnit 5テストの並行実行をする設定例
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<properties>
<configurationParameters>
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.config.strategy=fixed
junit.jupiter.execution.parallel.config.fixed.parallelism=20
</configurationParameters>
</properties>
<reportFormat>plain</reportFormat>
</configuration>
<dependencies>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-surefire-provider</artifactId>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
</dependency>
</dependencies>
</plugin>
JUnit 5.3から試験的に並行実行をサポー
トしている。

実行してみる。
@SpringJUnitConfig(classes = AppConfig.class)
class TestingTimeTest {
@Test
void テスト001() throws InterruptedException {
Thread.sleep(1000);
}
@Test
void テスト002() throws InterruptedException {}
・・・
@Test
void テスト020() throws InterruptedException {}
実行に1秒かかる
テストケースを20個用意
Spring TestContext Frameworkを
使用する。

20スレッドで並行実行した結果
並行実行通常実行
20.8秒 1.7秒
１２倍の高速化！

以下の場合は、並行実行NG！
・@DirtiesContextでテストメソッド実
行後にApplicationContextのキャッ
シュを破棄している場合
・@FixMethodOrderでテストメソッドの
実行順序を指定している場合
・テストケースがDBやファイルシステムの状
態に依存する場合

 まとめ

JUnitの前処理の直後、後処
理の直前で呼び出されるコール
バックメソッドが追加された
MockMVCを利用したテスト
の結果にリクエストBODYが出
力できるようになった
MockMVC利用時に「リダイレ
クト先URL」と「フォワード先
URL」を検証する際に、期待値
にURIテンプレートを指定でき
るようになった
XMLUnit 2.3のサポート
Spring 5変更点: その他の改善
https://github.com/spring-projects/spring-framework/wiki/What's-New-in-Spring-Framework-5.x#testing-improvements

 まとめ

Springは
テストがしやすい！

Spring 5で
さらにテスト
しやすくなった！

Springはテストでも、
最先端技術に
追従している！

アプリケーション開発
をするならSpring!

* https://qiita.com/kazuki43zoo/items/4a9ead225a9a9897af4a
* http://www.atmarkit.co.jp/ait/articles/0504/29/news022_3.html
* https://qiita.com/hshimo/items/1136087e1c6e5c5b0d9f
* https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-5.x
* https://www.infoq.com/jp/news/2017/10/junit5-released
* https://speakerdeck.com/rshindo/jjug-ccc-2018-spring
* https://oohira.github.io/junit5-doc-jp/user-guide/
* https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-5.x
* https://dev.classmethod.jp/testing/unittesting/junit-dynamic-test-case-using-runner/
* https://developer.ibm.com/dwblog/2017/best-new-features-junit-5/
* https://mike-neck.hatenadiary.com/entry/2017/01/01/160244
* https://www.oracle.com/webfolder/technetwork/jp/javamagazine/Java-MJ16-JUnit5.pdf
* https://www.slideshare.net/OgawaTakeshi/spring-tdd?ref=http://springfest2017.springframework.jp/
* https://gihyo.jp/dev/serial/01/tdd/0012
* https://www.slideshare.net/uesaka/build-insider-moqfakes
* https://qiita.com/1000k/items/aef6aed46b0fc34cc15e
* http://acro-engineer.hatenablog.com/entry/2017/12/07/120000
* https://speakerdeck.com/irof/dousiyoujunit5
* https://dev.classmethod.jp/testing/unittesting/where-is-junit5-aheaded/
* https://www.youtube.com/watch?v=h0Idcz71Aog
* http://www.ne.jp/asahi/hishidama/home/tech/java/junit/5/assertion.html
* Spring徹底入門
* JUnit実践入門
参考文献

Spring 5でSpring Testのここが変わる_公開版

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Spring 5でSpring Testのここが変わる_公開版

Similar to Spring 5でSpring Testのここが変わる_公開版 (20)

More from Yuichi Hasegawa

More from Yuichi Hasegawa (17)

Spring 5でSpring Testのここが変わる_公開版