【第1回】Java Testing Challenge LT大会 での登壇資料です
Spring Boot で実現するクリーンアーキテクチャとそのテスト戦略髙市 智章 (Tomoaki Takaichi)Dec, 25, 2019 【第1回】Java Testing Challenge LT大会#jjtc
View Slide
自己紹介@Takaichi00tomoaki.takaichi.5・髙市 智章(タカイチ トモアキ)・Java でのシステム開発・アジャイル開発実践・ショップ向けシステムの開発
❏ テスト戦略を立てていないと...❏ 人によってテストの実装方法が違う❏ 不必要なテストや、ビジネス上重要なロジックにテストがない❏ テストコードのメンテナンス性悪化テスト戦略立てていますか?
❏ 実践アジャイルテスト で書かれている内容❏ アジャイルテストの4象限❏ テストピラミッド❏ クリーンアーキテクチャー❏ 凹型レイヤーテスト戦略を立てる上で考えていること
❏ 様々なテストは大きく以下の4分類に分けることができる❏ 分類ごとに、自動 or 手動 or ツール でやるべきものが決定するアジャイルテストの4象限https://notta55.hatenablog.com/entry/2015/05/03/161631 より引用
❏ どのテストを優先して自動化するか?❏ 実行が速い/コストが低い単体テストを多く自動化する❏ 実行が遅い/コストが高い結合テスト、GUI のテストは多く自動化しない❏ 例: 境界値全網羅は単体テスト、業務シナリオテストは代表的なフロー数本テストピラミッドhttps://notta55.hatenablog.com/entry/2015/05/03/161631 より引用
❏ 中心の「ビジネスロジック」はそのままに、それ以外は交換可能なものとする考え方クリーンアーキテクチャーhttps://blog.tai2.net/images/CleanArchitecture.jpg より引用
❏ TERASOLUNA や 「Spring入門」などでも紹介されている設計パターン凹型レイヤーhttps://terasolunaorg.github.io/guideline/5.0.0.RELEASE/ja/_images/LayerDependencies.png より引用
❏ Controller, Service, Repository のそれぞれのレイヤ間で完結する単体テスト❏ レイヤ間で正しい振る舞いができているか?❏ Domain Model に対する単体テスト❏ ビジネスロジックは正しいか?❏ Controller ⇔ Repoistory ⇔ 対向先をモック という結合テスト❏ 結合した場合に正しい振る舞いをするか?Spring Boot テスト方針 ~REST API の場合~
❏ 実際にサンプルを実装してみましたSpring Boot DEMOhttps://github.com/Takaichi00/spring-boot-sample-api/tree/master/spring-boot-sapmle-api
❏ Front 部分からの開発が可能になる❏ 後ろの処理を実装していなくても Front の機能が実装可能❏ 「念の為の実装」をしなくて良い❏ Controller のプロトコルが変わった、データ取得元が DB ではなく REST API になった、といった場合でも Domain の変更をしなくて良い❏ 複数レイヤを並行して開発できる❏ ただしコミュニケーションコストがかかるためあまり実践はしていない❏ (結果として) テスタビリティが高いこの実装の良い点
❏ レイヤ間の値の詰め替えが退屈❏ 項目が多いほど値を詰め替える時間が膨大になり、テストも確認する項目が増え大変❏ 実装とテストが成熟してくると、例えば DB に項目を1つ追加して画面に返すのにも結構手間がかかる❏ 仮に REST API と画面を結合した GUI テストを実装し始めた場合、結合テストのメンテナンスが大変になることもこの実装の辛い点
❏ テストアワーグラス❏ GUI テストのコストは低下傾向にある❏ 結合テストはユーザーのニーズを満たしているか確認できるだろうか?❏ ATDD (受け入れ駆動開発)❏ Web 画面であれば Cucumber +Selenide を使用したテスト次の挑戦https://www.getautoma.com/blog/the-test-hourglass より引用
さいごにみなさんのテスト戦略もぜひ聞かせてください!!
ご清聴ありがとうございました