Tweet
Tweet

Slide 1

Slide 1 text

How to Test Server-side Kotlin #kotlinfest エムスリー株式会社 前原 秀徳 @maeharin エムスリー株式会社 鈴木 健太 @suusan2go 2018/8/25 Kotlin Fest 2018 1

Slide 2

Slide 2 text

自己紹介: 前原 秀徳 ● GitHub / Twitterは @maeharin ● 2014年5月にエムスリーに入社 ● エンジニアチームリーダー、グループ会社の取締役 を歴任後、2017年5月にサーバーサイドKotlinを用 いたレガシーシステムのリニューアルプロジェクトを 立ち上げ ● 自慢はブログ記事がはてなブックマーク1200を超え たこと 2

Slide 3

Slide 3 text

自己紹介: 鈴木 健太 ● GitHub / Twitterは @suusan2go ● 2017年11月に入社して、リニューアルプロジェクトに 参戦 ● 前職では主にRails触ってました ● リニューアルのプロジェクトでは、KotlinでAPIサーバ 書きつつ、フロントエンドはNuxt.js使って実装みたい なことを担当 ● 自慢は娘(２歳)が可愛いことです。 3

Slide 4

Slide 4 text

エムスリーご紹介 ・医療に関するWebサービスを多数展開 ・全世界で約400万人の医師会員 ・日本で約25万人の医師会員 4

Slide 5

Slide 5 text

Kotlinイン・アクションの翻訳陣が技術顧問・エンジニアフェロー エムスリー株式会社 技術顧問 藤原 聖 エムスリー株式会社 エンジニアフェロー 長澤 太郎 5

Slide 6

Slide 6 text

お話する内容 ● 10年前のレガシーシステムをサーバサイドKotlinでリプレイスしました。 その中で培ったKotlinのテストに関する話をします。 ● リプレイスしたレガシーシステムは2つ ○ 1. 医師のキャリア支援システム ○ 2. 薬剤師のキャリア支援システム ○ 事業規模感: 年間売上合わせて100億円超 ○ システムの規模感: それぞれテーブル数150〜200程度 ○ いずれのシステムも10年前の技術スタック（独自Java FW、ViewはXSLT） 6

Slide 7

Slide 7 text

当然ながら... 7 テストがない

Slide 8

Slide 8 text

テストのあるシステムへ ● APIサーバをKotlin + Spring Boot、フロントをRailsとVue.js（Nuxt.js）で リプレイス ○ テストのあるシステムへ ○ 2017年5月から開始。リリースはほぼ完了 ○ 約1500ケースのテストをKotlinで書いてきた 8

Slide 9

Slide 9 text

医師キャリア支援システム リニューアル後 REST APIサーバー 9

Slide 10

Slide 10 text

薬剤師キャリア支援システム リニューアル後 REST APIサーバー 10

Slide 11

Slide 11 text

お話する内容 ● 1部: Server-Side Kotlin testing libraries（前原） ○ サーバーサイドKotlin開発時に有用な主要テストライブラリを紹介 ○ Kotlinで使う際のTipsやハマりポイントも紹介 ● 2部: How do we test Server-Side Kotlin（鈴木） ○ 実際のプロジェクトでどのようにテストを書いていたかを紹介 ● 3部: Our test tools for Kotlin（鈴木） ○ テストのために発表者が作ったツールを紹介 11

Slide 12

Slide 12 text

お話する内容 今回の発表の対象範囲 サーバーサイドKotlinの単体テス ト、DBに接続したインテグレーション テストについてお話します。 E2Eテストの話やAndroidに特化し たテストの話は行いません。 12 アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点 - 増田 聡 氏 P8より引用 https://www.slideshare.net/satoshimasuda/ss-3241717 アジャイルテストの4象限

Slide 13

Slide 13 text

1部 Server-Side Kotlin testing libraries ● サーバーサイドKotlin開発時に有用な主要テストライブラリを紹介 ● Kotlinで使う際のTipsやハマりポイントも紹介 ● ライブラリ選定の際の参考になれば嬉しいです 13 ※ 各ライブラリの最新verは2018/8/24時点の情報

Slide 14

Slide 14 text

主要テスティングライブラリ をざっと分類 ※もちろんこれ以外にも 様々なライブラリが存在 赤色背景: 本資料で解説する分類 青字: 私達が使ったライブラリ 14

Slide 15

Slide 15 text

テスティングフレームワーク 15

Slide 16

Slide 16 text

JUnit4 ● https://github.com/junit-team/junit4 ● 最新ver: 4.12 ● Javaのテストライブラリのデファクトスタンダード ● アサーションライブラリであるhamcrestが組み込まれている ● 実績が多く、各種WAFの殆どが対応している 16

Slide 17

Slide 17 text

JUnit4 - Spring Bootのテスト用スターターキットもJUnit4 ● spring-boot-starter-test（ver2.0.4.RELEASE） 17

Slide 18

Slide 18 text

JUnit4 - Kotlinでも問題なく使用することができる ● @Testなどのアノテーション含め、Kotlinでも問題なく使用可能 ● 一部アノテーションはKotlinで使う時少しだけ留意点あり（後述） class SampleTest { @Test fun `1 + 2 は 3`() { val actual = sum(1, 2) assertEquals(3, actual) } 18

Slide 19

Slide 19 text

JUnit4 - Kotlin tips: JUnit4の@RuleをKotlinのプロパティにつけるとエラーになる ● Kotlinのvalからはprivateなフィールドとpublicなgetterが生成される ● @Ruleはそのままだと、フィールドに付与される(*) ○ * @Ruleの@Targetにより導かれる。詳細はKotlin公式Doc参照 ○ http://kotlinlang.org/docs/reference/annotations.html#annotation-use-site-targets ● @Ruleをつけるフィールドはpublicでなければいけないが、上記の通りフィール ドがprivateなので、must be publicというエラーになる ○ https://junit.org/junit4/javadoc/4.12/org/junit/Rule.html class SampleTest { @Rule val myRule = MyRule() // org.junit.internal.runners.rules.ValidationError: The @Rule 'myRule' must be public. 19

Slide 20

Slide 20 text

JUnit4 - 参考: Intellij IDEAでShow Kotlin Bytecodeした結果の抜粋 // Show Kotlin Bytecodeの結果抜粋 public final class SampleTest { private final LMyRule; myRule @Lorg/junit/Rule;() public final getMyRule()LMyRule; 20 privateなフィールドと publicなgetterが生成されている @Ruleはprivateなフィールドの方 に付与されている

Slide 21

Slide 21 text

JUnit4 - 対策1: @JvmFieldをつける ● @JvmFieldをつけるとpublicなフィールドが生成されるようになるため、 正常に動作するようになる // Kotlin class SampleTest { @JvmField @Rule val myRule = MyRule() ↓ // Show Kotlin Bytecodeの結果抜粋 public final class SampleTest { public final LMyRule; myRule @Lorg/junit/Rule;() 21

Slide 22

Slide 22 text

JUnit4 - 対策2: @get:Ruleとする ● @get:Ruleとするとgetterへのアノテーションであることを明示できる。@Rule はpublicなgetterにつけても動作するため、これでもOK ● https://kotlinlang.org/docs/reference/annotations.html#annotation-use-site-targets // Kotlin class SampleTest { @get:Rule val myRule = MyRule() ↓ // Show Kotlin Bytecodeの結果抜粋 public final class SampleTest { private final LMyRule; myRule public final getMyRule()LMyRule; @Lorg/junit/Rule;() 22

Slide 23

Slide 23 text

JUnit4 - Kotlin tips:@BeforeClassなどJavaのstaticメソッドにつけるアノテーション ● companion objectのメソッドに@BeforeClassなどのアノテーションをつ けるだけでは、何も実行されない ● @BeforeClassはJavaのpublicなstaticメソッドにつけるアノテーション だが、上記ではpublicなstaticメソッドとしては認識されていないから （Companionという参照を介する必要がある） class SampleTest { companion object { @BeforeClass fun foo() { println("foo") } // 実行されない } @Test fun `test 1`() {} @Test fun `test 2`() {} 23

Slide 24

Slide 24 text

JUnit4 - 対策: @JvmStaticをつける ● @JvmStaticをつける。これによりJava側からstaticメソッドとして呼び出 せるようになる ● 上記の例だとSampleTest.foo()として呼び出せるようになるので、JUnit が正常に動作する class SampleTest { companion object { @JvmStatic @BeforeClass fun foo() { println("foo") } } @Test fun `test 1`() {} @Test fun `test 2`() {} 24

Slide 25

Slide 25 text

JUnit4 - Kotlin tips:@DataPointsなどJavaのstaticフィールドにつけるアノテーション ● companion objectのプロパティにするだけではエラー ● Java側からはprivateなstaticフィールドとして扱われるので、msut be publicというエラーになる @RunWith(Theories::class) class TheoriesTest { companion object { @DataPoints val values = listOf( Data(1, 2, 3), Data(1, -2, -1) ) // DataPoint field values must be public 25

Slide 26

Slide 26 text

@RunWith(Theories::class) class TheoriesTest { companion object { @JvmField @DataPoints val values = listOf( Data(1, 2, 3), Data(1, -2, -1) ) } JUnit4 - 対策: @JvmFieldをつける ● @JvmFieldをつける。するとJava側からはpublicなstaticフィールドとし て扱えるようになるので、JUnitが正常に動作する 26

Slide 27

Slide 27 text

JUnit4 - KotlinでもJUnit4は問題なく使える ● Javaとの相互運用でハマったらIntellij IDEAでShow Kotlin Bytecodeするとヒ ントがあるかも ● Tools > Kotlin > Show Kotlin Bytecode 27

Slide 28

Slide 28 text

JUnit5 ● https://github.com/junit-team/junit5 ● 最新ver: 5.2.0 ● JUnit4の後継だが、JUnit4とは全く異なるフレームワーク ○ Lambda式対応。JUnit4のRuleやテストランナーの廃止など ○ JUnit Vintageを使えばJUnit4のテストケースの実行も可能 28

Slide 29

Slide 29 text

// Springが提供するJUnit5用拡張 @ExtendWith(SpringExtension::class) @SpringBootTest class UserServiceTest { @Autowired lateinit var userService: UserService @Autowired lateinit var dataSource: DataSource JUnit5 - Spring5はJUnit5を公式サポート ● https://docs.spring.io/spring/docs/current/spring-framework-refer ence/testing.html#integration-testing-annotations-junit-jupiter 29

Slide 30

Slide 30 text

import org.junit.jupiter.api.assertAll class Junit5BuildinKotlinHelperTest { @Test fun `junit5のassertAllをKotlinで実行`() { assertAll("number", { assertEquals(1, 1) }, { assertEquals(2, 2) } ) JUnit5 - JUnit5はKotlin用のヘルパーを提供している ● org.junit.jupiter.apiパッケージのトップレベル関数としてKotlinのヘル パーが定義されている ○ https://junit.org/junit5/docs/current/user-guide/ 30

Slide 31

Slide 31 text

Spek ● https://github.com/spekframework/spek ● 現在2.x準備中 ○ 1系 最新ver: 1.2.0 ○ 2系 最新ver: 2.0.0-alpha.1 ● Kotlinで書かれたテスティングフレームワーク。BDDスタイル ● JetBrainsの中の人が作っていた ● アサーションは含まないので、好きなアサーションライブラリと組み合わ せて使う 31

Slide 32

Slide 32 text

class SampleTest: Spek({ describe("userが0の時") { val repo = UserMemoryRepository() it("ユーザー数は0") { assertEquals(0, repo.count()) } it("存在しないuserを取得しようとするとnull") { assertNull(repo.findById(1)) } } 32 Spek - コード例

Slide 33

Slide 33 text

Spek - Spek 2.xは... ● KotlinConf 2017の発表（Testing Kotlin at Scale: Spek）では、「1.xは 使わず2.xを待った方がよく、2.xは2017年中に出そう」とのことであった が、まだ安定版はリリースされていない（2018/8/24の時点では、 v2.0.0-alpha.1） ○ https://www.youtube.com/watch?v=R425cc6XrvA 33

Slide 34

Slide 34 text

KotlinTest ● https://github.com/kotlintest/kotlintest ● 最新ver: 3.1.9 ● Kotlinで書かれたBDDテスティングフレームワーク ● 様々な書き方を選べる ● アサーションも含んでいる。JUnitをテスティングフレームワークとして使 い、アサーションにKotlinTestを使うという手もある ● Kotlin標準のkotlin.testシリーズとは別物 34

Slide 35

Slide 35 text

class SampleTest: StringSpec() { init { "userが0の時" { val repo = UserMemoryRepository() "ユーザー数は0" should { repo.count() shouldBe 0 } "存在しないuserを取得しようとするとnull" should { repo.findById(1) shouldBe null } 35 KotlinTest - コード例

Slide 36

Slide 36 text

KotlinTest - Spring用の拡張も用意されている ● https://github.com/kotlintest/kotlintest/blob/master/doc/reference.md#spring 36

Slide 37

Slide 37 text

現在のIntellij IDEAでは クラスごとにテスト実行は できるが、テストケースごとには実 行できない模様 ※ 以下のverで確認 ・Intellij IDEA ULTIMATE 2018.2 ・KotlinTest 3.1.9 37 KotlinTest - Intellij IDEAからのテスト実行

Slide 38

Slide 38 text

その他のテスティングフレームワーク ● TestNG ○ https://github.com/cbeust/testng ○ JUnit4と同じく歴史のあるテスティングフレームワーク ● Spock ○ https://github.com/spockframework/spock ○ groovy製 ○ power-assertが一つの特徴 38

Slide 39

Slide 39 text

私達はJUnit4を利用 ● spring-boot-starter-testのデフォルトに従った ● 開発当初Spring Boot1.5系が最新だった（JUnit5未サポートだった） ● 自分が使用するWebアプリケーションフレームワークとの相性、IDEとの相性を 調査してから導入することをオススメ 39

Slide 40

Slide 40 text

アサーションライブラリ 40

Slide 41

Slide 41 text

Hamcrest ● 基本的なアサーションはJUnit4に組み込まれている ● 応用的なアサーションはhamcrest-libraryを別途インストール ● Kotlinで使う場合はisが予約語なのでエスケープする必要あり assertThat(a, `is`(b)) // もしくは import org.hamcrest.CoreMatchers.`is` as Is assertThat(a, Is(b)) 41

Slide 42

Slide 42 text

AssertJ ● fluent（流れるような）インターフェース ● Kotlinで使うには特にハックが必要ない assertThat(a).isEqualTo(b) 42

Slide 43

Slide 43 text

KotlinTestのアサーション ● KotlinTestはテスティングフレームワークだが、アサーションも含んでい る ● 3系からはモジュールが3つに別れており、アサーションである kotlintest-assertionsだけimportして使える ○ https://github.com/kotlintest/kotlintest/blob/65aabf75d0ef0eac7d67fed1f11c 1932b41993ce/CHANGELOG.md#version-30x---march-29-2018 ● テスティングフレームワークとしてJUnit4を使い、アサーションに KotlinTestを使うということも可能 a shouldBe b 43

Slide 44

Slide 44 text

Kotlin製のアサーションライブラリは沢山ある // kotlin.test assertEquals(actual = a, expected = b) // Kluent a shouldEqual b // HamKrest assert.that(a, equalTo(b)) // Expekt a.should.equal(b) // assertk assertThat(a).isEqualTo(b) 44

Slide 45

Slide 45 text

（参考）私達はAssertJを使った ● spring-boot-starter-testのデフォルトに従った ● fluentインターフェースが好みだったため（主観） ● どのライブラリを選ぶのかは好みが分かれる所だと思うが、一つのプロ ジェクト内で複数のアサーションライブラリが乱立しないようにはした方 がよいと思う 45

Slide 46

Slide 46 text

モックライブラリ 46

Slide 47

Slide 47 text

Mockito ● https://github.com/mockito/mockito ● 最新ver: 2.21.3 ● Javaのモックライブラリのデファクトスタンダード ● Kotlinで使う際のハマりポイント2つ ○ １，finalクラス/メソッドをモックできない問題 ○ ２，Mockito.any()問題 47

Slide 48

Slide 48 text

Mockito - 問題1. Mockitoはfinalクラス/メソッドをモックできない ● Mockitoはfinalクラス/メソッドをモックできない ● 一方、Kotlinのクラス/メソッドはデフォルトでfinal ● 従って、Kotlinのクラス/メソッドをそのままmockしようとすると「final classのためモックできません」というエラーになる ● 主な対処法4つ class ApiClient { fun foo(): String { return "api response" } } val mock = mock(ApiClient::class.java) // Mockito cannot mock/spy because : - final class 48

Slide 49

Slide 49 text

Mockito - 対処法1: 愚直にopen open class ApiClient { open fun foo(): String { return "api response" } } val mock = mock(ApiClient::class.java) ● モックする対象のクラス、メソッドを手動でopenする 49

Slide 50

Slide 50 text

Mockito - 対処法2: インターフェースを使う interface ApiClient { fun foo(): String } class ApiClientImpl: ApiClient { override fun foo(): String { return "api response" } } val mock = mock(ApiClient::class.java) ● テスト対象クラスにインターフェースを実装させ、インターフェースをモッ クする 50

Slide 51

Slide 51 text

Mockito - 対処法3: allopenプラグイン ● Kotlinのallopenプラグインを使い、モック対象をopenする ● Springの場合、kotlin-springプラグインを使ってSpringのBeanはopen しているケースがほとんどだと思うので、あまり意識することは無いかも しれない ○ https://kotlinlang.org/docs/reference/compiler-plugins.html#spring-support 51

Slide 52

Slide 52 text

// 独自アノテーションを作る package com.maeharin annotation class OpenForMock // モック対象のクラスに独自アノテーションを付与 @com.maeharin.OpenForMock class ApiClient { fun foo(config: ApiConfig): String { return "real" } } Mockito - 対処法3: allopenプラグイン 52

Slide 53

Slide 53 text

Mockito - 対処法3: allopenプラグイン // build.gradle buildscript { dependencies { classpath "org.jetbrains.kotlin:kotlin-allopen:$kotlin_version" } } apply plugin: 'kotlin-allopen' allOpen { // 独自アノテーションをallOpenの対象に指定 annotation('com.maeharin.OpenForMock') } 53

Slide 54

Slide 54 text

Mockito - 対処法4: Mockitoのmock-maker-inlineを有効化 mock-maker-inline src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker に以下のテキストを書く ● mockito2.1.0からexperimentalな機能として提供されている ○ https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2#mock- the-unmockable-opt-in-mocking-of-final-classesmethods ● experimentalな機能ということは留意が必要 54

Slide 55

Slide 55 text

Mockito - 問題2: NotNullな引数にMockito.any()を使うとランタイムでエラー ● Mockito.any()の戻り値の型はプラットフォーム型のジェネリクス（T!）なのでコ ンパイルは通る ● しかし、Mockito.any()はランタイムでnullを返す仕様。KotlinはNotNullな引 数に対してプラットフォーム型を渡すと、ランタイム時にメソッドをコールする 前にnullチェックするため、エラーになる open class ApiClient { open fun foo(config: Config /** NotNullな引数 */){ … } } val mockClient = Mockito.mock(ApiClient::class.java) Mockito.`when`(mockClient.foo(Mockito.any())).thenReturn("dummy") // java.lang.IllegalStateException: Mockito.any() must not be null 55

Slide 56

Slide 56 text

Mockito - 参考: Intellij IDEAでShow Kotlin Bytecodeした結果 mockClient.foo(Mockito.any()) ↓ INVOKESTATIC org/mockito/Mockito.any ()Ljava/lang/Object; DUP LDC "Mockito.any()" INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkExpressionValueIsNotNull (Ljava/lang/Object;Ljava/lang/String;)V CHECKCAST ApiConfig INVOKEVIRTUAL ApiClient.foo (LApiConfig;)Ljava/lang/String; 56

Slide 57

Slide 57 text

Mockito - 対処法1: 独自ヘルパーを作る private fun myAny(): T { return Mockito.any() } Mockito.`when`(mock.foo(myAny())).thenReturn("dummy") ● 戻り値の型がKotlinのジェネリクスとなるメソッドでMockito.any()をラップ。 すると、ランタイムのnullチェックがスキップされる ○ https://stackoverflow.com/questions/30305217/is-it-possible-to-use-mockito-in-k otlin/30308199 57

Slide 58

Slide 58 text

Mockito - 対処法2: Kotlin用ラッパーmockito-kotlinを使う import com.nhaarman.mockitokotlin2.* // mockito-kotlinのany() whenever(mock.foo(any())).thenReturn("dummy") ● Mockito.any()ではなく、mockito-kotlinが提供するany()を使うと前述 のnullの問題は起きない 58

Slide 59

Slide 59 text

Mockito-Kotlin ● https://github.com/nhaarman/mockito-kotlin ● MockitoのKotlin用ラッパー。あくまでもラッパーなので、基本機能は Mockitoを利用 ● 1系と2系でパッケージ名異なる（現最新ver: 1.6.0 / 2.0.0-RC1） ● Kotlin用のDSLを提供（`when`と同義のwheneverなど） ● mockito-kotlinのany()を使えば、前述のMockito.any()問題は起きない ● ※前述のfinal問題を自動でカバーしてくれるわけではないので、そこは mockitoのmock-maker-inlinを有効化など前述の対策を講じる必要あ り 59

Slide 60

Slide 60 text

import com.nhaarman.mockitokotlin2.* // モック作成 val mock: ApiClient = mock { on { foo(any()) } doReturn "dummy" } // モックを注入して実行 SampleService(mock).exec(ApiConfig()) // モックのメソッドが呼ばれたことを検証 verify(mock).foo(any()) Mockito-Kotlin - コード例 60

Slide 61

Slide 61 text

MockK ● https://github.com/mockk/mockk ● Kotlin製のモックライブラリ ● 最新ver: 1.8.6 ● デフォルトでfinalクラス/メソッドをモックできる ● mockkのany()を使えばMockito.any()問題は起きない 61

Slide 62

Slide 62 text

import io.mockk.* // モック作成 val mock:ApiClient = mockk() every { mock.foo(any()) } returns "dummy" // モックを注入して実行 SampleService(mock).exec(ApiConfig()) // モックのメソッドが呼ばれたことを検証 verify(exactly = 1) { mock.foo(any()) } MockK - コード例 62

Slide 63

Slide 63 text

私達はMockito-Kotlinを利用 ● spring-boot-starter-testのデフォルトはMockito ● Mockito.any()問題の解消やKotlin用のDSLを提供してくれるのが便利 なので、MockitoのラッパーであるMockito-Kotlinを使うことにした 63

Slide 64

Slide 64 text

DBセットアップライブラリ 64

Slide 65

Slide 65 text

DBUnit ● http://dbunit.sourceforge.net/ ● 最新ver: 2.6.0 ● XML、CSVなどからテストデータをセットアップできる ● データベースの状態を検証することもできる ● 2002年にver1.0がリリースされた歴史あるJavaライブラリ 65

Slide 66

Slide 66 text

66 DBUnit - コード例

Slide 67

Slide 67 text

@Before fun setup() { Class.forName(dbDriver) conn = DriverManager.getConnection(dbUrl, dbUser, dbPassword) val iDBConn = DatabaseConnection(conn) val iDataSet = FlatXmlDataSetBuilder().build(File("src/test/resources/dbunit-datas/users.xml")) DatabaseOperation.CLEAN_INSERT.execute(iDBConn, iDataSet) } @Test fun `test 1`() { val stmt = conn.createStatement() val rs = stmt.executeQuery("select * from users order by id asc") assertTrue(rs.next()) assertEquals("maeharin", rs.getString("name")) } 67 DBUnit - コード例

Slide 68

Slide 68 text

DBUnit - 課題 ● 重複記述が多くなる ● 雛形を元に一部の値だけ変えたパターンをプログラマブルに作るといっ たことが行いづらい ● カラムに変更があった時の変更箇所が多い 68

Slide 69

Slide 69 text

DbSetup ● https://github.com/Ninja-Squad/DbSetup ● 最新ver: 2.1.0 ● xmlなどの外部ファイルではなく「コード」でテストデータを生成できる Javaライブラリ ● Kotlin用のDSLも提供してくれている（DbSetup-kotlin） 69

Slide 70

Slide 70 text

dbSetup(dest) { deleteAllFrom("users") insertInto("users") { mappedValues( "id" to 1, "name" to "maeharin", "job" to "ENGINEER", "status" to "ACTIVE", "age" to 30, "is_admin" to false, "created_timestamp" to LocalDateTime.now() ) } }.launch() 70 DbSetup - コード例

Slide 71

Slide 71 text

他の選択肢 ● WAFの機能を利用する（例: Spring Testの@Sql） ● O/Rマッパorデータアクセスライブラリのinsert系メソッドを利用する（例: MyBatis、Doma2、Exposed等） 71

Slide 72

Slide 72 text

私達はDbSetup-kotlinを少し工夫して利用 ● （背景）私達はDBアクセスライブラリにはDoma2を使っている ○ 私達はDomaのEntityはKotlinではなくJavaで定義した ○ DomaのDaoを使ってテストデータをinsertするという手もあるが、Javaなのでフィクス チャのプロパティのIDE補完がされない ● DbSetupと自作ツールであるFacltinを使うことで、Kotlinのdata classを 用いてプログラマブルにテストデータを生成する仕組みを作った ○ 詳細は第3部で紹介 72

Slide 73

Slide 73 text

1部まとめ ● テスティングライブラリは、WAFとIDEとの相性も加味して決めることをオ ススメ ● アサーションはHamcrestやAsserJが鉄板だが、プロジェクトの中で乱 立しないようにだけ留意しつつ、好みのライブラリを使えばよいと思う ● モックはKotlinまわりで少しハマりポイントがあるため、mockito-kotlinを 使うとよい（もしくはmockk） ● DBテストセットアップはDbSetup+Factlin（後述）がオススメ 73

Slide 74

Slide 74 text

2部 How do we test Server-side Kotlin ● 実際のプロジェクトでどのようにテストを書いていたか紹介します ○ テスト対象のアプリケーションについて ○ テスト戦略について ○ アプリケーションサービス、JSON APIのテストについてのTips 74

Slide 75

Slide 75 text

テスト対象のアプリケーション構成についておさらい ● SpringBoot + Kotlin で実装されたAPIサーバ ● 10年弱運用されてきたアプリケーションのリニューアル！(Java独 自FW) ● 新アプリケーションはオニオンアーキテクチャをベースにした構成 ○ プレゼンテーション層 ○ アプリケーション層 ○ ドメイン層 ○ インフラストラクチャ層 75

Slide 76

Slide 76 text

Kotlin + Spring Boot API サーバ REST APIでやりとり もしくは バックエンドのAPIとしてSpring Boot + Kotlin 76

Slide 77

Slide 77 text

オニオンアーキテクチャ [DDD]ドメイン駆動 + オニオンアーキテクチャ概略　より引用 77

Slide 78

Slide 78 text

パッケージ構成 78 ● presentation ○ WEBのエンドポイント(controllerとか) ● domain ○ ドメインエンティティ、バリューオブジェクト ● application ○ アプリケーションサービス(ユースケース) ● infrastructure ○ DBアクセス、他サービスとのREST API連携など

Slide 79

Slide 79 text

プレゼンテーションの実装イメージ @RestController class TaskController(val taskService: TaskService) { @GetMapping("/tasks/{id}") fun findTask(@PathVariable("id") id: Int): TaskResponse { val task = taskService.findById(id) return TaskResponse(id = task.id, title = task.title) } } // Responseのクラスを必ず作成し、ドメイン層のクラスをそのまま返さない data class TaskResponse(val id: Int, val title: Title) 79

Slide 80

Slide 80 text

アプリケーションサービスの実装イメージ @Service class TaskService( // infrastructure層に定義したクラスをコンストラクタインジェクションで DIする private val taskRepository: TaskRepository, private val userRepository: UserRepository ) { fun assignTask(taskId: TaskId, assigneeId: UserId): Task { val task = taskRepository.findById(taskId) ?: throw NotFoundExcpetiopn() val assignee = userRepository.findById(assigneeId) ?: throw NotFoundException() task.assignedTo(assignee) 　　　 return taskRepository.save(task) } } 80

Slide 81

Slide 81 text

Repositoryの実装イメージ @Repository class DomaPrefectureRepository( private val prefectureEntityDao: PrefectureEntityDao ): PrefectureRepository { override fun findAll(): List { val entities = prefectureEntityDao.selectAll() // Domaから取得 return entities.map { // Domaから取得したものを Domain層で定義したクラスにマッピングしなおす Prefecture( id = it.id, name = it.name, status = PrefectureStatus.valueOf(it.status), // レガシーなカラムをそのまま使わずにマッピング isPrimary = it.primaryFlag == 2 // レガシーなカラムをそのまま使わずにマッピング ) } } } 81

Slide 82

Slide 82 text

このアーキテクチャのpros ● 各レイヤの責務が明確になるので変更に強い ○ ある箇所を変更したときの影響範囲が明確 ● 技術的な関心事とビジネスロジックをある程度切り離して考えられる ○ 特に歴史的な経緯を含むDBのスキーマとビジネスロジックを切り離 して考えられるようになった 82

Slide 83

Slide 83 text

このアーキテクチャのcons ● 記述量は比較的に増える傾向にある ○ 特に各レイヤー間でのマッピングは結構大変なので、開発当初は 結構辛い・・・ ● 単純な処理しかしないAPIでは、単純にデータを各レイヤで受け渡すだ けになることがある 83

Slide 84

Slide 84 text

pros/consを踏まえたテスト方針 ● テスト対象は基本的にアプリケーションサービスより上の層 ○ ※ドメイン層はロジックの複雑なものだけテスト ● アプリケーションサービスに対するテスト ○ アプリケーションとして要求される仕様を満たしているかをテスト ○ 基本的にこの層を厚めに書くことで仕様の正しさを担保でき、ドメイ ン層のリファクタリングもしやすくする ● JSON APIに対するテスト ○ レスポンスの正しさ をテスト ○ 意図したユーザーのみがアクセスできることをテスト 84

Slide 85

Slide 85 text

Presentation Application Domain Infrastructure 各テストがカバーするレイヤーの範囲 JSON APIのテスト アプリケーションサービスのテスト PostgreSQL 外部API ElasticSearch 85

Slide 86

Slide 86 text

アプリケーションサービスの テストにおけるTips 86

Slide 87

Slide 87 text

Presentation Application Domain Infrastructure アプリケーションサービスのカバー範囲 モックしない PostgreSQL 外部API ElasticSearch 開発者毎に Docker モック アプリケーションサービスのテスト 87

Slide 88

Slide 88 text

アプリケーションサービスのテストコード // アプリケーションサービスのテストコードサンプル class ConsultantServiceStopConsultantTest : ServiceTestBase() { // Testではコンストラクタインジェクションできないので lateinitでフィールドインジェクション @Autowired private lateinit var consultantService: ConsultantService @Autowired private lateinit var consultantRepository: ConsultantRepository @Autowired private lateinit var positionRepository: PositionRepository @Test fun コンサルタントアカウントを idで取得できること() { val consultantOutput = consultantService.showConsultantSimpleInfo(2) assertThat(consultantOutput.id).isEqualTo(2) } @Test fun コンサルタントアカウントを停止できること () { consultantService.stopConsultant(12) // テスト対象のサービス実行 // コンサルタントの求人が全て削除されていること val positions = positionRepository.findByConsultantId(12) assertThat(positions).isEmpty() } } 88

Slide 89

Slide 89 text

アプリケーションサービスのテストコード @Test fun コンサルタントアカウントを idで取得できること() { val consultantOutput = consultantService.showConsultantSimpleInfo(2) assertThat(consultantOutput.id).isEqualTo(2) } @Test fun コンサルタントアカウントを停止できること () { consultantService.stopConsultant(12) // テスト対象のサービス実行 // コンサルタントの求人が全て削除されていること val positions = positionRepository.findByConsultantId(12) assertThat(positions).isEmpty() } 89

Slide 90

Slide 90 text

アプリケーションサービスのテスト方針 ● アプリケーションサービスの結合テスト ○ DBアクセス => モックにしない ● テストフレームワークはJUnit4。アサーションはAssertJ ○ 当初はKotlinTestを使っていたが、Inttelijで実行したときに差 分をInttelijがいい感じにしてくれないので、AssertJに切り替 え ● 戻り値をテストするのはもちろん、場合によってはDB変更もテスト する ● テストでDBをどのように扱ったかをお話します。 90

Slide 91

Slide 91 text

DBアクセスはモックにしなかった ● アプリケーションの構造上、各Infrastructureレイヤーからドメインオブジェク トへのマッピングが必要になるので、少なくともその部分が例外にならない ことはテストしておきたい ● 特にKotlinの場合 Null / Not Nullが厳密なので、DB上 Null を取りうるカラ ムの値を Not Null のプロパティにマッピングするようなコードがあると簡単 に実行時例外になってしまう ● まだデータアクセスライブラリ(Doma2)によるSQL実行が最低限例外なく実 行できることも確認したい ● マッピングのテストをかいた上でRepositoryをモックにする方向もあったが、 DbSetupを用いるとDB上のデータの生成が容易だったのでモックにしない 選択をした 91

Slide 92

Slide 92 text

データのセットアップをどのようにおこなったか ● DBのセットアップにはDbSetup-kotlinを使用 ● DbSetup-Kotlinのコードは、Factlinというライブラリ(※後で紹介 します！)によりスキーマから自動生成 ● Factlinにより、DBのデータセットアップもRailsのFactoryBotのよ うに平易に取り扱うことができるようになった 92

Slide 93

Slide 93 text

// Factlinという独自ライブラリで作成した Fixtureクラスを活用して以下のようにセットアップできる @Before fun setUp() { dbSetup(DataSourceDestination(dataSource)) { init() // suusan2goユーザーを作成 insertUserFixture(UserFixture(name = "suusan2go", job = "engineer", age = 25)) // maeharinユーザーを作成 insertUserFixture(UserFixture(name = "maeharin", job = "engineer", age = 35)) }.launch() } Factlinを活用したDBデータのセットアップコード(※後ほど解説します) 93

Slide 94

Slide 94 text

DBがどのように変更されたかをテストする ● DBが意図した状態に変更されたことをチェックしたい ○ 特にDBとドメインエンティティのマッピングが単純ではない場 合や、意図しないデータを更新していないか、意図した件数 更新しているかなどを厳密にチェックしたい場合 ● AssertJ-DBを用いてDBの状態をテストした ● AsserJ-DBはDBの変更をAssertJのようなシンタックスでテストで きるライブラリ 94

Slide 95

Slide 95 text

@Test fun メッセージ送信上限をリセットできること() { // 特定テーブルの変更トラッキングを定義 val changes = Changes(Table(dataSource, "consultant")) // 変更のトラッキングを開始 changes.setStartPointNow() // テスト対象のサービスを実行 consultantService.resetConsultantRemainingMessageCount() // 変更のトラッキングを終了 changes.setEndPointNow() assertThat(changes).onTable("consultant") .hasNumberOfChanges(1) .change() .column("id").valueAtEndPoint().isEqualTo(someConsultant.id) .column("remaining_message_count").valueAtStartPoint().isEqualTo(0) .valueAtEndPoint().isEqualTo(4) } 95

Slide 96

Slide 96 text

AssertJ-DBのcons ● 細かなDBの変更を全てAssertJ-DBでテストするのは、シンタックス的に 少しつらい ● 変更を検知するテーブルを絞っても、テストは通常よりも時間がかかる ようになる ● 全てをAssertJ-DBでテストしているわけではなく、RepositoryでDBから 引き直してテストしているものが多いです 96

Slide 97

Slide 97 text

JSON APIのテストにおけるTips 97

Slide 98

Slide 98 text

JSON APIのテストがカバーする範囲(おさらい) Presentation Application Domain Infrastructure モックしない PostgreSQL 外部API ElasticSearch 開発者毎に Docker モック JSON APIのテスト 98

Slide 99

Slide 99 text

JSON APIのテストのTIPS ● Kotlinならではのテストリクエストの書き方 ● JSON APIの効率的なテストの仕方 99

Slide 100

Slide 100 text

JSON APIのテストをわかりやすく、宣言的に書く ● 普通にSpringのMockMVCを使用してコントローラへの リクエストをテスト ● Kotlinの拡張関数を活用すると認証が必要なAPIや、 どのようなリクエストなのかを宣言的に記述できます 100

Slide 101

Slide 101 text

テストコード @Test fun コンサルタント一覧APIへのアクセステスト() { // 管理者はAPIにアクセスできる getはMockMvcRequestBuildersのStaticメソッド get("/admin/api/users").asUser(mockMvc, adminEmail, "password").also { request -> mockMvc.perform(request) .andExpect(status().isOk) // ステータスコードのチェック } // 普通のユーザーではアクセスできない get("/admin/api/users").asUser(mockMvc, email, "password").also { request -> mockMvc.perform(request) .andExpect(status().isForbidden) } // ログインしていないとアクセスできない get("/admin/api/users").also { request -> mockMvc.perform(request) .andExpect(status().isForbidden) } } 101

Slide 102

Slide 102 text

拡張関数の開設 // 事前にログイン用のAPIにアクセスして、ログイン状態のセッションを RequestBuilderに渡しておく fun MockHttpServletRequestBuilder.asUser( mockMvc: MockMvc, email: String, password: String ): MockHttpServletRequestBuilder { val loginRequest = LoginRequest(email, password) val session = MockHttpSession() val request = MockMvcRequestBuilders .post("/admin/api/login") .withJson(loginRequest) .accept(MediaType.APPLICATION_JSON_VALUE) .session(session) mockMvc.perform(request).andExpect(status().is2xxSuccessful) this.session(session) return this } 102

Slide 103

Slide 103 text

// 渡されたオブジェクトを JSON化してリクエストボディに詰める fun MockHttpServletRequestBuilder.withJson( object: Object ): MockHttpServletRequestBuilder { this.contentType(APPLICATION_JSON_UTF_8) this.content(ObjectMapper().writeValueAsString(object) return this } 103

Slide 104

Slide 104 text

拡張関数の開設 val hogeRequestDto = HogeRequestDto(piyo = “hogehoge”, fuga = “hogehoge”) // Util的なものを使って書くとこんな感じになる val testRequest = post("/api/some_resources") RequestUtil.asUser(testRequest, email, password) RequestUtil.withJson(testRequest, hogeRequestDto) // 拡張関数を組み合わせて宣言的にリクエストを組み立てられる post("/api/some_resources") .asUser(mockMvc, email, password).withJson(hogeRequestDto) 104

Slide 105

Slide 105 text

JSONのアサーション (JsonUnit) ● spring-boot-starter-testではJSONassertが入ってくるが、JsonUnit の方が差分表示が見やすいため、JsonUnitを主に利用した ○ https://github.com/skyscreamer/JSONassert ○ https://github.com/lukas-krecan/JsonUnit 105

Slide 106

Slide 106 text

// JsonUnit // どのキーの値がどう違うのかが明確 val a = "{\"id\":1,\"friends\":[1,2]}" val b = "{\"id\":1,\"friends\":[3,4]}" assertJsonEquals(a, b) // java.lang.AssertionError: JSON documents are different: //Different value found in node "friends[0]", expected: <1> but was: <3>. //Different value found in node "friends[1]", expected: <2> but was: <4>. 106

Slide 107

Slide 107 text

● プロパティが数十個あってネストしているAPIの「期待値」を手で書いて いくのは骨が折れる ● 最初のテスト実行時に正常なAPIレスポンスの期待値をファイルに保存 し、このファイルを元に期待するJSONフォーマットを記述した ● このJSONファイルを期待値としてJsonUnitでアサートするようにする と、スピーディーにテストを書くことができた ● また、これにより意図せずAPIの形が変わった場合にもテストで気がつ けるようになった 期待するJSONをどのように用意するか 107

Slide 108

Slide 108 text

@Test fun `コンサルタント詳細情報を表示できること `() { var actual = mockMvc.perform(request) .andExpect(status().isOk) .andReturn().response.contentAsString assertEqualToJsonFileOrSave(actual, "path/to/expected/json") } // 独自ヘルパーメソッド // - jsonファイルがない状態で一度実行すると指定パス配下にファイルができる // - jsonファイルがない状態ではテスト自体は failする // - ファイルが有る場合は、JsonUnitで内容の一致をチェックする fun assertEqualToJsonFileOrSave(result: Any, path: String) 108

Slide 109

Slide 109 text

おまけ：カバレッジ ● カバレッジの取得にはJacocoを活用 ● 少し前までData Classから自動生成されるコードについてのカバレッジ が0%になってしまうため、カバレッジがほぼ意味を成さない値になって いた ● 0.8.2からはKotlinのテストでもカバレッジが正しく取得できる！ 109

Slide 110

Slide 110 text

例：こんなクラスのカバレッジを考える data class GeoCode( val latitude: Double, val longitude: Double ) { fun calculateDistances(other: GecCode): Long {} } @Test fun 正しく距離が計算されること(){ val geoCode = GeoCode(xxx, yyy) val otherGeoCode = GeoCode(zzzz, aaaa) assertEquals(geoCode.calculateDistance(otherGeoCode), xxxx) } 110

Slide 111

Slide 111 text

0.8.1以前 111

Slide 112

Slide 112 text

0.8.2以降 112

Slide 113

Slide 113 text

0.8.2はなんと今週リリース 113

Slide 114

Slide 114 text

How do we test Servier-Side Kotlinのまとめ ● アプリケーションサービスより上の層を中心にテストしてます ● アプリケーションサービスの結合テストのTips ○ DBSetupでのデータセットアップ ○ AssertJ-DBを使ったデータベース状態のテスト ● JSON APIでのテストのTips ○ 拡張関数でテスト用のリクエストを宣言的に記述できる ○ JSONUnit & JSONファイル生成でJSONのテストを容易に ● テストのカバレッジはjacocoで。 0.8.2からはData Classもカバレッジが正しく取得できるように！ 114

Slide 115

Slide 115 text

3部 Our test tools for Kotlin ● テストのために発表者が作ったツールたちの紹介 ○ Factlin ○ kotlin-fill-class 115

Slide 116

Slide 116 text

Factlin (by @maeharin) ● DbSetupのシンタックスは平易とはいえ、カラムの多いテーブルに対 するセットアップコードを一から書くのは大変 ● Factlinを使うことで、既存のデータベーススキーマから、DbSetup用 のコードを生成できる ● テストフィクスチャ用のクラスでNull / Not Nullを区別できる ● テストフィクスチャ用のクラスはKotlinのdata classになっているた め、copyメソッドを用いて「少しだけパラメータが異なる似たようなフィ クスチャ」を簡単に生成できる 116

Slide 117

Slide 117 text

Factlinの生成コード例 CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(256) NOT NULL, job VARCHAR(256) NOT NULL DEFAULT 'engineer', status VARCHAR(256) NOT NULL DEFAULT 'ACTIVE', age INTEGER NOT NULL, score NUMERIC NOT NULL, is_admin BOOLEAN NOT NULL, birth_day DATE NOT NULL, nick_name VARCHAR(256), created_timestamp TIMESTAMP WITHOUT TIME ZONE NOT NULL, updated_timestamp TIMESTAMP WITHOUT TIME ZONE ); ● 左記のようなスキーマに対して、 factlinのgradle タスクを実行する 　　./gradlew factliin 117

Slide 118

Slide 118 text

// DBのカラムへのコメントも自動で反映されます！ // Fixture Class data class UsersFixture ( val id: Int = 0, // primary key val name: String = "", // user name val job: String = "", // job name val status: String = "", // activate status val age: Int = 0, // user age val score: BigDecimal = 0.toBigDecimal(), // game score val is_admin: Boolean = false, // user is admin user or not val birth_day: LocalDate = LocalDate.now(), // user birth day val nick_name: String? = null, // nick name val created_timestamp: LocalDateTime = LocalDateTime.now(), val updated_timestamp: LocalDateTime? = null ) 118

Slide 119

Slide 119 text

// DbSetupの拡張関数を自動生成 fun DbSetupBuilder.insertUsersFixture(f: UsersFixture) { insertInto("users") { mappedValues( "id" to f.id, "name" to f.name, "job" to f.job, "status" to f.status, "age" to f.age, "score" to f.score, "is_admin" to f.is_admin, "birth_day" to f.birth_day, "nick_name" to f.nick_name, "created_timestamp" to f.created_timestamp, "updated_timestamp" to f.updated_timestamp ) } } 119

Slide 120

Slide 120 text

// Factlinという独自ライブラリで作成した Fixtureクラスを活用して以下のようにセットアップできる @Before fun setUp() { dbSetup(DataSourceDestination(dataSource)) { init() // suusan2goユーザーを作成 insertUserFixture(UserFixture(name = "suusan2go", job = "engineer", age = 25)) // maeharinユーザーを作成 insertUserFixture(UserFixture(name = "maeharin", job = "engineer", age = 35)) }.launch() } Factlinを活用したDBデータのセットアップコード 120

Slide 121

Slide 121 text

日本語の解説記事あります ● 以下をご参照ください！！！！ ● DBスキーマからKotlinのテストフィクスチャを自動生成するgradleプラグ インを作った 121

Slide 122

Slide 122 text

Kotlin Fill Class (by @suusan2go) ● コンストラクタを書くのを少しだけ楽にしてくれるIntellij Plugin ● Named argumentsの形式でコンストラクタの呼び出しを補完してくれる ● Kotlin標準のクラスならデフォルト値もついでに与えてくれる 122

Slide 123

Slide 123 text

モチベーション ● 小さなクラスならよいが、歴史的な経緯により大量のプロパティを持 たざるえないクラスはテストのためにコンストラクタを呼び出して初期 化するのが大変しんどい ● テストのスコープからは少し外れるが、我々のプロジェクトでは各レ イヤ間でクラス間で値をマッピングするコードがとても多かった。 Intellij IDEAでは補完、足りないプロパティの警告はしてくれるもの の、一つずつnamed arguments形式で書くのがだるい 123

Slide 124

Slide 124 text

たとえばこんなクラスをインスタンス化するコード書くの辛くないですか data class User( val id: Int, val name: String, val age: Int, val address: String, val firstName: String, val lastName: String, val firstNameKana: String, val lastNameKana: String, val favoriteSongName: String, val favoriteFruitsName: String, val favoriteSport: String, val favoriteProgramingLanguage: String, val favoriteBook: String, val isMarried: Boolean, val hasDependent: Boolean, val CommutingTime: Int, val nearestStationName: String, val isAdmin: Boolean, val educationBackground: String, val githubAccount: String, val twitterAccount: String, val facebookAccount: String, val linkedinAccount: String, val lineAccount: String, val m3Account: String, val birthday: LocalDate, val motherTongue: String, val occupation: String, val bestSubject: String, val deathblow: String, val youtubeAccount: String, val lovesKotlin: Boolean ) 124

Slide 125

Slide 125 text

Kotlin Fill Classを使わない場合 125

Slide 126

Slide 126 text

Kotlin Fill Classのデモ 126

Slide 127

Slide 127 text

Kotlin Fill Classの実装について ● Inttelijプラグインの作り方自体は今回の発表のスコープから外れるので以下を ご参照ください！！！ ● そしてダウンロードしてください！！！ ● まだ機能は荒削りなのでpulll-requestお待ちしてます！ ● Kotlinでコンストラクタをシュッと書くためにIntellijのプラグインを作った 127

Slide 128

Slide 128 text

３部 Our test tools for kotlinのまとめ ● 以下のようなツールで開発の効率化を行いました ○ Factlin DBのスキーマからDBSetupのコードを自動生成 ○ 大量のプロパティを持つクラスの生成にkotlin-fill-class ● KotlinはJavaの資産が使えるとはいえ、まだまだこういったKotlin用のツー ルが少ない印象なので今がチャンス！かもしれません。 128

Slide 129

Slide 129 text

最後に ● サーバーサイドKotlinでもテストはバッチリ書けます！ ● エムスリーではサーバーサイドKotlinを用いたプロジェクトが複数立ち上 がっています。We’re Hiring!!! 129