Spring Boot で実現する クリーンアーキテクチャとそのテスト戦略

【第1回】Java Testing Challenge LT大会 での登壇資料です

Transcript

1. Spring Boot で実現する
   クリーンアーキテクチャとそのテスト戦略
   髙市 智章 (Tomoaki Takaichi)
   Dec, 25, 2019 【第1回】Java Testing Challenge LT大会
   #jjtc
   

   View Slide

2. 自己紹介
   @Takaichi00
   tomoaki.takaichi.5
   ・髙市 智章（タカイチ トモアキ）
   ・Java でのシステム開発
   ・アジャイル開発実践
   ・ショップ向けシステムの開発
   

   View Slide

3. ❏ テスト戦略を立てていないと...
   ❏ 人によってテストの実装方法が違う
   ❏ 不必要なテストや、ビジネス上重要なロジックにテス
   トがない
   ❏ テストコードのメンテナンス性悪化
   テスト戦略立てていますか？
   

   View Slide

4. ❏ 実践アジャイルテスト で書かれている内容
   ❏ アジャイルテストの4象限
   ❏ テストピラミッド
   ❏ クリーンアーキテクチャー
   ❏ 凹型レイヤー
   テスト戦略を立てる上で考えていること
   

   View Slide

5. ❏ 様々なテストは大きく以下の4分類に分けることができる
   ❏ 分類ごとに、自動 or 手動 or ツール でやるべきものが決定する
   アジャイルテストの4象限
   https://notta55.hatenablog.com/entry/2015/05/03/161631 より引用
   

   View Slide

6. ❏ どのテストを優先して自動化するか？
   ❏ 実行が速い/コストが低い単体テストを多く自動化する
   ❏ 実行が遅い/コストが高い結合テスト、GUI のテストは多く自動化しない
   ❏ 例: 境界値全網羅は単体テスト、業務シナリオテストは代表的なフロー数本
   テストピラミッド
   https://notta55.hatenablog.com/entry/2015/05/03/161631 より引用
   

   View Slide

7. ❏ 中心の「ビジネスロジック」はそのままに、それ以外は交
   換可能なものとする考え方
   クリーンアーキテクチャー
   https://blog.tai2.net/images/CleanArchitecture.jpg より引用
   

   View Slide

8. ❏ TERASOLUNA や 「Spring入門」などでも紹介されてい
   る設計パターン
   凹型レイヤー
   https://terasolunaorg.github.io/guideline/5.0.0.RELEASE/ja/_images/LayerDependencies.png より引用
   

   View Slide

9. ❏ Controller, Service, Repository のそれぞれのレイヤ間
   で完結する単体テスト
   ❏ レイヤ間で正しい振る舞いができているか？
   ❏ Domain Model に対する単体テスト
   ❏ ビジネスロジックは正しいか？
   ❏ Controller ⇔ Repoistory ⇔ 対向先をモック という結合
   テスト
   ❏ 結合した場合に正しい振る舞いをするか？
   Spring Boot テスト方針 ~REST API の場合~
   

   View Slide

10. ❏ 実際にサンプルを実装してみました
    Spring Boot DEMO
    https://github.com/Takaichi00/spring-boot-sample-api
    /tree/master/spring-boot-sapmle-api
    

    View Slide

11. ❏ Front 部分からの開発が可能になる
    ❏ 後ろの処理を実装していなくても Front の機能が実装可能
    ❏ 「念の為の実装」をしなくて良い
    ❏ Controller のプロトコルが変わった、データ取得元が DB では
    なく REST API になった、といった場合でも Domain の変更を
    しなくて良い
    ❏ 複数レイヤを並行して開発できる
    ❏ ただしコミュニケーションコストがかかるためあまり実践はしていない
    ❏ (結果として) テスタビリティが高い
    この実装の良い点
    

    View Slide

12. ❏ レイヤ間の値の詰め替えが退屈
    ❏ 項目が多いほど値を詰め替える時間が膨大になり、テ
    ストも確認する項目が増え大変
    ❏ 実装とテストが成熟してくると、例えば DB に項目を1
    つ追加して画面に返すのにも結構手間がかかる
    ❏ 仮に REST API と画面を結合した GUI テストを実装し始
    めた場合、結合テストのメンテナンスが大変になることも
    この実装の辛い点
    

    View Slide

13. ❏ テストアワーグラス
    ❏ GUI テストのコストは低下傾向にある
    ❏ 結合テストはユーザーのニーズを満たしているか確
    認できるだろうか？
    ❏ ATDD (受け入れ駆動開発)
    ❏ Web 画面であれば Cucumber +
    Selenide を使用したテスト
    次の挑戦
    https://www.getautoma.com/blog/the-test-hourglass より引用
    

    View Slide

14. さいごに
    みなさんのテスト戦略もぜひ聞かせてください！！
    

    View Slide

15. ご清聴ありがとうございました
    

    View Slide