$30 off During Our Annual Pro Sale. View Details »

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

Takaichi00
December 25, 2019

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

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

Takaichi00

December 25, 2019
Tweet

More Decks by Takaichi00

Other Decks in Technology

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