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
新規アプリの単体テスト戦略 / unit_tests_strategy_of_new_app
Search
uhooi
October 28, 2022
Programming
3
920
新規アプリの単体テスト戦略 / unit_tests_strategy_of_new_app
iOS Test Online
https://testonline.connpass.com/event/261910/
uhooi
October 28, 2022
Tweet
Share
More Decks by uhooi
See All by uhooi
snacks.nvim内のセットアップ不要なプラグインを紹介 / introduce_snacks_nvim
uhooi
2
600
Develop iOS apps with Neovim / vimconf_2024
uhooi
2
610
暴走のウホーレン 〜想いってのはvimrcにしないと伝わらないんだぜ〜 / iosdc_japan_2024
uhooi
1
520
SwiftLintのカスタムルールを作るための正規表現入門 / swiftlint_regex
uhooi
1
150
最古の関数型言語「Lisp」ことはじめ / lisp_in_kamiyama
uhooi
1
330
会社PCでrm -rf ~した話 / rm_rf_choron
uhooi
18
24k
クソアプリを作ってみた💩 / kusojaku
uhooi
0
610
Apple提供アプリのナビゲーションバーアイテムクイズ / 20231110-hig
uhooi
2
290
個人開発のiOSアプリでUI/UXを標準に寄せてみた / 20230919_orochi
uhooi
0
970
Other Decks in Programming
See All in Programming
XP, Testing and ninja testing
m_seki
3
230
ニーリーにおけるプロダクトエンジニア
nealle
0
750
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
140
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
680
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
都市をデータで見るってこういうこと PLATEAU属性情報入門
nokonoko1203
1
590
PipeCDのプラグイン化で目指すところ
warashi
1
250
VS Code Update for GitHub Copilot
74th
2
600
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
730
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
340
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
220
イベントストーミング図からコードへの変換手順 / Procedure for Converting Event Storming Diagrams to Code
nrslib
2
610
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Fireside Chat
paigeccino
37
3.5k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
YesSQL, Process and Tooling at Scale
rocio
173
14k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
940
Into the Great Unknown - MozCon
thekraken
39
1.9k
Designing for humans not robots
tammielis
253
25k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Producing Creativity
orderedlist
PRO
346
40k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Transcript
新規アプリの 単体テスト戦略 2022.10.28(Fri) iOS Test Online @the_uhooi
iOS app developer @uhooi @uhooi @the_uhooi
入社前の会話 新規アプリ作って!
入社前の会話 新規アプリ作って! はい!
ウホーイ入社 ウホーイ 入社
・UI: フル SwiftUI ・リアクティブ: Combine ・非同期処理: Swift Concurrency (async/await) ・アーキテクチャ:
MVVM ・その他: SwiftPM によるマルチモジュール、KMM ※開発中なので変更される可能性が大いにあります。 新規アプリの技術選定
最初に考えた単体テストの戦略
できる限り にする 単体テストが不要な設計 最初に考えた単体テストの戦略
できる限り にする 単体テストが不要な設計 必要な にする 単体テストを書きやすい設計 最初に考えた単体テストの戦略
01 単体テストが な 設計にする 不要
アーキテクチャ(MVVM) View View Model UseCase KMM
単体テストを書く層を明文化する View View Model UseCase KMM : 単体テストを書かない : 必要に応じて単体テストを書く
: 単体テストを書く
View 層の単体テストを書かない理由 UI/UX を確認するため、 必ず から 手動でテストを行う
どうしたら View 層から単体テストをなくせる? View View Model UseCase KMM : 単体テストを書かない
: 必要に応じて単体テストを書く : 単体テストを書く
ロジックを減らせば単体テストも減らせる View View Model UseCase KMM 少なくしたい 多くする : 単体テストを書かない
: 必要に応じて単体テストを書く : 単体テストを書く View 層からロジックを なくすのが理想 ロジック
ロジックを減らすには? ロジックを減らすには?
分岐をなくせばロジックを減らせる ロジックを減らすには? 分岐 をなくす (if 文や switch 文)
View に分岐がある(Before) // Before // View 層 if viewModel.uiState.isLoading {
Text("ロード中です。") } else { Text("ロードが完了しました。") }
View から分岐をなくす(After) // After // View 層 Text(viewModel.uiState.loadingText) // ViewModel
層 var loadingText: String { isLoading ? "ロード中です。" : "ロードが完了しました。" }
View から分岐をなくす(After) // After // View 層 Text(viewModel.uiState.loadingText) // ViewModel
層 var loadingText: String { isLoading ? "ロード中です。" : "ロードが完了しました。" } View 層の分岐を ViewModel 層に寄せる
それでも View から分岐は完全にはなくせない // View 層 struct MonstersView: View {
var body: some View { if viewModel.uiState.monsters.isEmpty { EmptyMonsterListView() } else { MonsterListView(monsters: viewModel.uiState.monsters) } } }
それでも View から分岐は完全にはなくせない // View 層 struct MonstersView: View {
var body: some View { if viewModel.uiState.monsters.isEmpty { EmptyMonsterListView() } else { MonsterListView(monsters: viewModel.uiState.monsters) } } } View の出し分けなどの 分岐はなくせない
それでも View から分岐は完全にはなくせない // View 層 struct MonstersView: View {
var body: some View { if viewModel.uiState.monsters.isEmpty { EmptyMonsterListView() } else { MonsterListView(monsters: viewModel.uiState.monsters) } } } View の出し分けなどの 分岐はなくせない monsters が空のときの UI の確認が手間
そこでプレビュー そこでプレビュー
Xcode 上で SwiftUI の View を確認できる
「UI を確認するだけの手動テスト」をなくせる プレビューでは ・端末のサイズ ・ライト / ダークモード ・データの最小 / 最大値
・エラー時の View etc... 様々な状態をかんたんに作り出せる
02 単体テストを 設計にする 書きやすい
ViewModel 層以下の単体テストを書きやすくしたい View View Model UseCase KMM : 単体テストを書かない :
必要に応じて単体テストを書く : 単体テストを書く
UI フレームワークを View 層のみでインポートする View View Model UseCase KMM SwiftUI
Combine : 単体テストを書かない : 必要に応じて単体テストを書く : 単体テストを書く View 層のみで UI を完結させる
UI フレームワークを View 層のみでインポートする View View Model UseCase KMM SwiftUI
Combine : 単体テストを書かない : 必要に応じて単体テストを書く : 単体テストを書く ViewModel 層以下がロジックに集中でき、 単体テストが書きやすくなる
Task があると単体テストしにくい(Before) // Before // ViewModel 層 struct FooViewModel: ObservableObject
{ func didTapLoginButton() { Task { await login() } } }
Task があると単体テストしにくい(Before) // Before // ViewModel 層 struct FooViewModel: ObservableObject
{ func didTapLoginButton() { Task { await login() } } } ログイン処理を待たずに テストが終了してしまう
ViewModel 層のメソッドを非同期にする(After) // After // ViewModel 層 struct FooViewModel: ObservableObject
{ func didTapLoginButton() async { await login() } }
ViewModel 層のメソッドを非同期にする(After) // After // ViewModel 層 struct FooViewModel: ObservableObject
{ func didTapLoginButton() async { await login() } } 非同期にすると 並行処理もしやすくなる
Task を View 層に書く(After) // After // View 層 struct
FooView: View { // ... Task { await viewModel.didTapLoginButton() } // ... }
ちなみに…
ちなみに… まだ単体テストを書いていません これから書きます!
03 まとめ
まとめ 設計を工夫することで、 、 できる 不安定な単体テストを減らし 安定した単体テストを書きやすく
まとめ View View Model UseCase KMM UI ロジック Task 単体テストしにくい
単体テストしやすい
まとめ View View Model UseCase KMM 単体テストしにくい・しやすいものを 分離し、単体テストする層を明確にする UI ロジック
Task 単体テストしにくい 単体テストしやすい
まとめ View View Model UseCase KMM UI ロジック Task 単体テストを書かない層(View
層)は プレビューや手動テストで品質を担保する 単体テストしにくい 単体テストしやすい