Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Spring Boot で実現する クリーンアーキテクチャとそのテスト戦略
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Takaichi00
December 25, 2019
Technology
3.2k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Spring Boot で実現する クリーンアーキテクチャとそのテスト戦略
【第1回】Java Testing Challenge LT大会 での登壇資料です
Takaichi00
December 25, 2019
More Decks by Takaichi00
See All by Takaichi00
individual_or_organization
takaichi00
0
300
自分から始めるアジャイルの道 ~内発的動機をきっかけに変わった価値観~
takaichi00
0
470
Java developer introduced to Rust-ADC2022
takaichi00
0
310
野球人・落合博満さんから学ぶ、アジャイルなマインドセット・プラクティス
takaichi00
1
910
【CICD2021】デプロイメントパイプラインの原理原則を再確認する / Confirm Deployment Pipeline Principle
takaichi00
11
4.7k
【JTF2021】SonarQube をより有効活用する / Effective SonarQube
takaichi00
1
2.7k
JJUG CCC 2021 Spring-Resolving OOME with JFR
takaichi00
2
3.8k
【Yahoo! JAPAN Agile 2nd】野球人・落合博満さんから学ぶスクラムマスター / デベロッパー
takaichi00
0
2.8k
【Developers Boost 2020】凡人エンジニアの生存戦略
takaichi00
1
3.3k
Other Decks in Technology
See All in Technology
「最後に責任を取るのはチーム」— 人間のPRレビューを最小化してアップデートしたメンタルモデル
jnishime_dresscode
0
580
型は壁、Rustでもバグを直すな、表現できなくせよ
nwiizo
13
2k
Compose 新機能総まとめ / What's New in Jetpack Compose
yanzm
0
170
はじめてのWDM
miyukichi_ospf
1
140
「早く出す」より「事業に効く」 ── 顧客の業務サイクルから逆算するAI時代の二重ループ開発と「変化の設計者」 / devsumi2026
rakus_dev
1
220
インフラと開発の垣根を超えていき!〜元AWSインフラエンジニアがAWS開発で奮闘している話〜
hatahata021
1
170
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
620
ボーイスカウトルールでメモリやスキルを改善しよう
azukiazusa1
1
790
公式ドキュメントの歩き方etc
coco_se
0
100
AI時代のエンジニアキャリアについて今一度考える
sakamoto_582
2
1.5k
10年目を迎えた「ABEMA」がどのように AI 活用を推進して、AI 駆動開発にシフトしているのか / How ABEMA, entering its 10th year, is promoting the use of AI and shifting toward AI-driven development
miyukki
0
130
脱金融のフューチャー・デザイン / Future Design Beyond Finance
ks91
PRO
0
150
Featured
See All Featured
Evolving SEO for Evolving Search Engines
ryanjones
0
240
Git: the NoSQL Database
bkeepers
PRO
432
67k
Bash Introduction
62gerente
615
220k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
72
40k
Balancing Empowerment & Direction
lara
6
1.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
A Soul's Torment
seathinner
6
3.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.7k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
550
30 Presentation Tips
portentint
PRO
1
350
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.4k
Transcript
Spring Boot で実現する クリーンアーキテクチャとそのテスト戦略 髙市 智章 (Tomoaki Takaichi) Dec, 25,
2019 【第1回】Java Testing Challenge LT大会 #jjtc
自己紹介 @Takaichi00 tomoaki.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 DEMO https://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 より引用
さいごに みなさんのテスト戦略もぜひ聞かせてください!!
ご清聴ありがとうございました