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
290
自分から始めるアジャイルの道 ~内発的動機をきっかけに変わった価値観~
takaichi00
0
460
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
気軽に使える"情報のハブ"としてのNotion活用 〜フロー情報の集積点 と、 Claude Code × Notion AI〜
syucream
1
160
FPC(フレキシブル)基板にZephyr実装してみた。
iotengineer22
0
120
iAEONの段階的リアーキテクト戦略 / iAEON's_Gradual_Re-architecture_Strategy
aeonpeople
0
230
データサイエンスを価値につなげるプロジェクト設計 〜 DS一年目が現場で得た気づき 〜
ysd113
1
280
IaC コードを資産へ:AWS CDK 社内ライブラリと横断展開 / aws-summit-japan-2026
gotok365
5
1.1k
脱SaaS!FDEを支えるプロビジョニングと分離設計
knih
0
240
脆弱性対応、どこで線を引くか
rymiyamoto
1
420
2026 TECHFRESH 畢業分享會 - 開發日常大解密!從領域驅動到企業級上線
line_developers_tw
PRO
0
1.3k
Bucharest Tech Week 2026 - Reinventing testing practices in the AI era
edeandrea
PRO
1
170
[AWS Summit Japan 2026]迷っているあなたへ_小さな一歩が、やがて自分を助けてくれる
sh_fk2
1
170
AIはどのように 組織のアジリティを変えるのか?
junki
4
1k
「勝手に広まる」人気 AI エージェントを爆速で作ろう!(AWS Summit Japan 2026講演資料)
minorun365
PRO
9
2k
Featured
See All Featured
Visualization
eitanlees
152
17k
The agentic SEO stack - context over prompts
schlessera
0
820
Between Models and Reality
mayunak
4
340
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Fireside Chat
paigeccino
42
4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.7k
Facilitating Awesome Meetings
lara
57
7k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
180
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
490
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Statistics for Hackers
jakevdp
799
230k
Making Projects Easy
brettharned
120
6.7k
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 より引用
さいごに みなさんのテスト戦略もぜひ聞かせてください!!
ご清聴ありがとうございました