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
Takaichi00
December 25, 2019
Technology
0
2.5k
Spring Boot で実現する クリーンアーキテクチャとそのテスト戦略
【第1回】Java Testing Challenge LT大会 での登壇資料です
Takaichi00
December 25, 2019
Tweet
Share
More Decks by Takaichi00
See All by Takaichi00
自分から始めるアジャイルの道 ~内発的動機をきっかけに変わった価値観~
takaichi00
0
140
Java developer introduced to Rust-ADC2022
takaichi00
0
220
野球人・落合博満さんから学ぶ、アジャイルなマインドセット・プラクティス
takaichi00
1
770
【CICD2021】デプロイメントパイプラインの原理原則を再確認する / Confirm Deployment Pipeline Principle
takaichi00
11
4.3k
【JTF2021】SonarQube をより有効活用する / Effective SonarQube
takaichi00
0
2.3k
JJUG CCC 2021 Spring-Resolving OOME with JFR
takaichi00
2
3.1k
【Yahoo! JAPAN Agile 2nd】野球人・落合博満さんから学ぶスクラムマスター / デベロッパー
takaichi00
0
2.6k
【Developers Boost 2020】凡人エンジニアの生存戦略
takaichi00
1
2.6k
【ソフトウェアテスト自動化カンファレンス2020】CI パイプラインでのテスト戦略とその実現方法
takaichi00
3
5.3k
Other Decks in Technology
See All in Technology
Snykで始めるセキュリティ担当者とSREと開発者が楽になる脆弱性対応 / Getting started with Snyk Vulnerability Response
yamaguchitk333
2
180
20241214_WACATE2024冬_テスト設計技法をチョット俯瞰してみよう
kzsuzuki
3
450
KnowledgeBaseDocuments APIでベクトルインデックス管理を自動化する
iidaxs
1
260
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
2
2.2k
成果を出しながら成長する、アウトプット駆動のキャッチアップ術 / Output-driven catch-up techniques to grow while producing results
aiandrox
0
280
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
120
ブラックフライデーで購入したPixel9で、Gemini Nanoを動かしてみた
marchin1989
1
520
第3回Snowflake女子会_LT登壇資料(合成データ)_Taro_CCCMK
tarotaro0129
0
190
社内イベント管理システムを1週間でAKSからACAに移行した話し
shingo_kawahara
0
180
re:Invent をおうちで楽しんでみた ~CloudWatch のオブザーバビリティ機能がスゴい!/ Enjoyed AWS re:Invent from Home and CloudWatch Observability Feature is Amazing!
yuj1osm
0
120
Snowflake女子会#3 Snowpipeの良さを5分で語るよ
lana2548
0
230
watsonx.ai Dojo #5 ファインチューニングとInstructLAB
oniak3ibm
PRO
0
160
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
347
20k
BBQ
matthewcrist
85
9.4k
Into the Great Unknown - MozCon
thekraken
33
1.5k
The Cost Of JavaScript in 2023
addyosmani
45
7k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
We Have a Design System, Now What?
morganepeng
51
7.3k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
810
Facilitating Awesome Meetings
lara
50
6.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.1k
Typedesign – Prime Four
hannesfritz
40
2.4k
Docker and Python
trallard
42
3.1k
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 より引用
さいごに みなさんのテスト戦略もぜひ聞かせてください!!
ご清聴ありがとうございました