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
マルチモジュールなプロジェクトでテストはどう変わるか? / How change testin...
Search
tkmnzm
February 07, 2019
Programming
13
21k
マルチモジュールなプロジェクトでテストはどう変わるか? / How change testing in modular architecture
tkmnzm
February 07, 2019
Tweet
Share
More Decks by tkmnzm
See All by tkmnzm
AndroidアプリのUIバリエーションをあの手この手で確認する / Check UI variations of Android apps by various means
tkmnzm
1
510
Androidアプリの良いユニットテストを考える / Thinking about good unit tests for Android apps
tkmnzm
5
7k
Google I:O 2023 Androidの自動テストアップデートまとめ / Google I:O 2023 Android Testing Update Recap
tkmnzm
0
560
コルーチンのエラーをテストするためのTips / Tips for testing Kotlin Coroutine errors
tkmnzm
0
860
Androidのモダンな技術選択にあわせて自動テストも アップデートしよう / Update your automated tests to match Android's modern technology choices
tkmnzm
3
2k
SWET dev-vitalチームによるプロジェクトの健康状態可視化の取り組み / SWET dev-vital team's efforts to visualize the health of the project
tkmnzm
1
1.2k
モバイルアプリテスト入門 / Getting Started with Mobile App Testing
tkmnzm
1
450
25分で作るAndroid Lint / Android Lint made in 25 minutes
tkmnzm
0
830
2年半ぶりのプロダクト開発であらためて感じた自動テストの大切さ / realized the importance of automatic testing with product development for the first time in two and a half years
tkmnzm
1
740
Other Decks in Programming
See All in Programming
o1モデルのプロンプトエンジニアリングって?
ktc_wada
0
450
AWS Lambda Web Adapterを活用する新しいサーバーレスの実装パターン
tmokmss
6
5.2k
Progressive Web Apps for Rails developers
siaw23
2
510
クラウドサービスの 利用コストを削減する技術 - 円安の真南風を感じて -
pyama86
3
230
ビット演算の話 / Let's play with bit operations
kaityo256
PRO
3
140
NANIMACHI
naokiito
0
920
Cloud Adoption Frameworkにみる組織とクラウド導入戦略(縮小版)
tomokusaba
1
120
Compose Multiplatform과 Ktor로 플랫폼의 경계를 넘어보자
kwakeuijin
0
200
CSC305 Lecture 01
javiergs
PRO
1
140
Assembling the Future: crafting the missing pieces of the Ruby on Wasm puzzle
skryukov
0
120
はじめてみよう量子プログラミング
itokoichi01
0
280
推しの夫に恋のGPS「ときメーター」#M5Stack #IoT #M5JPTour2024
riyu
0
220
Featured
See All Featured
A designer walks into a library…
pauljervisheath
201
24k
RailsConf 2023
tenderlove
28
830
Optimising Largest Contentful Paint
csswizardry
31
2.8k
Designing on Purpose - Digital PM Summit 2013
jponch
114
6.9k
Testing 201, or: Great Expectations
jmmastey
38
7k
Git: the NoSQL Database
bkeepers
PRO
425
64k
A Philosophy of Restraint
colly
202
16k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
41
6.5k
The Invisible Side of Design
smashingmag
296
50k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
124
18k
From Idea to $5000 a Month in 5 Months
shpigford
380
46k
[RailsConf 2023] Rails as a piece of cake
palkan
49
4.7k
Transcript
マルチモジュールな プロジェクトで テストはどう変わるか? Nozomi Takuma 2019/2/7 DroidKaigi2019
自己紹介 Nozomi Takuma SWET@DeNA所属 (2018/3~) Androidとテストが好き
はじめに
マルチモジュールって? :app :featureA :featureB アプリの実装を 複数のモジュールに 分割する
:app featueA package featureB package これまでのアーキテクチャ appモジュール内に 実装をまとめた モノリシックな構成
:app :featureA :featureB :app featueA package featureB package
app/build.gradle
なぜマルチモジュールにするのか? • 差分ビルドによるビルド時間短縮のため • App BundleやInstant App対応のため • それぞれの機能を分離させることで機能 間の独立性を保つため
マルチモジュールプロジェクトの テストで変わらないこと • テストを書くこと • テストの書きかた
マルチモジュールプロジェクトの テストで変わる3つのポイント 1. DI 2. テスト方針 3. メトリクス収集
DI
DI(Dependency Injection)って? • コンポーネントの依存を外から渡せる ようにする • テストをしやすくするためのパターン として利用される • DI
LibraryとしてDaggerが有名
マルチモジュールでのDI悩みポイント 1. モジュール間の依存関係を クリーンに保ちたい 2. 依存の定義をモジュール内で完結 させたい
モジュール間の依存をクリーンに保ちたい app module feature module 依存解決にapp module内のクラスが 必要な場合、循環参照が発生する可能性がある
Daggerで困る例
Daggerで困る例 feature module内の Activity app module内の Application
依存の定義をモジュール内で完結させたい • どのように依存が解決されるかの定義は モジュール内で完結できるとうれしい • DaggerでいうとModuleクラスの定義 など
マルチモジュールでのDI DIのやりかたやDIライブラリの使い方に よっては、前述の悩みポイントに対応する ため書き方や構成の変更が必要になる
話しきれないので... 『マルチモジュールプロジェクトでの Dagger2を用いたDependency Injection』 02/07 11:20 - 11:50@Hall A
サンプル • Dagger-Android https://github.com/tkmnzm/MultiModulePlayground
テスト方針
モジュール化によって得られるメリット • ビルド時間短縮による開発速度向上 • 意味のあるまとまりに分けることによって 他モジュールへの影響範囲が小さくなる
動作確認もモジュール内で完結 できるようにしたらどうだろう? モジュール化のメリットを得るために
モジュール内で動作確認を完結できると • 各モジュールの動作確認をするために 全体のapkをビルドしなくてよい • 動作確認済みのモジュールを使用する ことで、モジュールを結合したときの 動作確認が楽になる
モジュール内でどんな動作確認が できていたら嬉しいか? テスト方針を考える問いかけ
とあるモノリシックなプロジェクトの例 Presenter UseCase Repository 呼び出していることを 意味する矢印
とあるモノリシックなプロジェクトの例 Presenter UseCase Repository ユニット テスト
• レイヤー内の代表的なクラスのユニット テストは充実していた(UseCase,Repo など) • しかし上記以外の実装もたくさんあり テストが手薄なところもあった とあるモノリシックなプロジェクトの例
• このモジュールの動作確認はいまある テストだけだと足りない気がする... • この例の場合、UI部分やITテストが 不足していた モジュールとして分割してみた時
• まとまりの責務を考えるきっかけ • モノリシックなプロジェクトではレイ ヤーごとにどうテストするかを考える ことが多かったが、モジュール毎とい う新しい視点が生まれる モジュールとして切り出す
• モジュール内のテスト • モジュールをまたいだテスト モジュールのテスト方針を考えてみよう
モジュール内のテスト
モジュールの設計時に考えたいこと • モジュールの責務 • モジュールのテスト範囲
自動テストの手段はいろいろ ITテスト ユニット テスト UIテスト
例えばこんなモジュール① Utility Utility Utility
例えばこんなモジュール① Utility Utility Utility ユニット テスト
例えばこんなモジュール② Logic Logic Android PF
Logic Logic Android PF 例えばこんなモジュール② ユニット テスト IT テスト
Logic Logic Android PF 例えばこんなモジュール② IT テスト
例えばこんなモジュール③ Activity Logic Android PF
Activity Logic Android PF 例えばこんなモジュール③ UI テスト IT テスト
Activity Logic Android PF UI テスト 例えばこんなモジュール③
方針考えたけど何から手を付ける? ユニットテストで十分なところは ユニットテストからはじめる ユニット テスト
導入の容易さ ITテスト ユニット テスト UIテスト
FBサイクルの速さ ITテスト ユニット テスト UIテスト
ITテスト・UIテスト ユニットテストでは動作確認として 不足している部分に追加していく しかし、自分自身はAndroid PFが絡むテ ストは避けがちだった
ITテスト・UIテスト ユニットテストでは動作確認として 不足している部分に追加していく しかし、自分自身はAndroid PFが絡むテ ストは避けがちだった AndroidのAPIが絡むテストも導入しやすくなるよう 環境が変わりつつある
Project Nitrogen 実行環境の差分を統一した • API • Test Runner
API Robolectric上でも実機上でも実行可能
Test Runner
Project Nitrogenに期待すること • ローカルでのテスト: Robolectric上で素早く実行 • CIでのテスト: 実機やVirtual Device上など fidelity(忠実度)の高い環境で実行
None
現状は... • Robolectricで実行するには: src/testにテストコードを配置 • Deviceで実行するには: src/androidTestにテストコードを配置
ワークアラウンド
モジュール内のテストまとめ • モジュールの責務とテスト範囲を考える • まずはユニットテストからはじめる • ITテストやUIテストはつまづきがち だが、導入しやすい環境が整いつつある
もしテストを書く時間がなくても • テスタビリティは意識して実装したい • いざテストを書こうとしたときにテスト が書きにくい状態になっていると まずはリファクタリングが必要になる
モジュールをまたいだテスト
テストの方針 Module B Module A Module A Module B モジュールごとにテスト
結合してテスト
モジュールごとにテスト FeatureBをモック化
結合してテスト 実インスタンスや Spyを使用
モジュールをまたぐといっても • テストの書き方はいままでと変わらない • 他モジュールへの依存を外から渡すように していれば、これまでどおりテストダブル が使用できる
どれを選択する? • ケース・バイ・ケース • 自分のプロダクトではどんな不具合が起き やすいか?(単体でも拾える?結合しない とだめ?)というのは判断に使えそう
テストメトリクス収集
テストメトリクス Android開発でよく 使われているのは • JUnit実行結果 • Jacoco
マルチモジュールでのテストメトリクス収集 各モジュールのレポートをまとめて 見たい場合、結果のマージが必要
Jacocoについては... 『Spek2+MockK+JaCoCoでイケてるUnit Test環境を手に入れろ!』 02/08 11:20-11:50@Room 1
PIT Java、その他JVM言語用MutationTesting ツール http://pitest.org/
Mutation Testing • プロダクトコードを機械的に変更し、 変更されたコードに対してテストを実行 • テストが失敗するかを確認することで、 テストコードが振る舞いの変更を検知 できるかチェックする
例: Conditionals Boundary Mutator if (hoge <= 5) { //
do something } if (hoge < 5) { // do something } hogeが5のときの 振る舞いが Mutatorによって変更
例: Conditionals Boundary Mutator if (hoge <= 5) { //
do something } if (hoge < 5) { // do something } hogeが5のときの 振る舞いが Mutatorによって変更 hogeが5のときの テストが正しく書かれて いれば失敗するはず...
例: Conditionals Boundary Mutator テストを実行し... • テストが失敗する: OK • テストが成功する:
NG 境界値チェックなど、不足しているテストケースを 見つける手助けをしてくれる
PITのレポート
PITのレポート
PITのうれしいところ • Mutation Coverageと Line Coverageが見られる • Android用GradlePluginがある • Kotlinのサポートが進んでいる
実行結果のマージ: マージ処理抜粋
実行結果のマージ: PIT設定抜粋
サンプル https://github.com/tkmnzm/MultiModulePlayground • PIT導入 • PITレポートのマージ
まとめ
1. DI 2. テスト方針 3. メトリクス収集 まとめ • DIのやりかたによっては 書き方や構成の変更が必要
• 詳細はその他のDI関連 セッションで!
1. DI 2. テスト方針 3. メトリクス収集 まとめ • モジュール設計時に モジュールのテスト方針を
考えてみる • IT・UIテストもハードルが 下がりつつある
1. DI 2. テスト方針 3. メトリクス収集 まとめ • 各モジュールの結果を マージする必要がある
• 不足しているテストケース を見つけてくれるPITを ご紹介
ご清聴ありがとうございました