テストコードの観点から見たSansanのアーキテクチャ変遷

■ イベント
モバイルアプリ開発における良いテストコードの考え方
https://trident-qa.connpass.com/event/320151/

■ 発表者
Mobile Applicationグループ
原田 拓眞

■ Android エンジニア採用情報
https://media.sansan-engineering.com/android-engineer

■ iOS エンジニア採用情報
https://media.sansan-engineering.com/ios-engineer

Transcript

1. テストコードの観点から⾒た Sansanのアーキテクチャ変遷 Sansan株式会社 技術本部 Mobile Applicationグループ 原⽥拓眞 モバイルアプリ×良いテストコード
2. ⾃⼰紹介 Sansan株式会社 技術本部 Mobile Applicationグループ 原⽥拓眞 - 2014年Sansan株式会社新卒⼊社 - 当初はC#/.NET FrameworkのWebエンジニア （WinFormsやWPFも触った） - 2018年末頃からAndroidに転向 - 当時kotlin書いた経験無し - 最近⽝を飼い始めました。
3. - Sansan Androidアプリのアーキテクチャの変遷とユニット テストの関係性 - Sansan モバイルアプリの「テスト」 - KotlinMultiplatformでの開発におけるTips 本⽇の内容
4. 良いテストコードは 良いアーキテクチャから⽣まれる
5. Sansanのアーキテクチャの変遷を テストコードという観点から⾒ていきます
6. 『単体テストの考え⽅/使い⽅(Vladimir Khorikov著)』によれば、 単体テストの⽬的は「ソフトウェア開発プロジェクトの成⻑を持続可能なものにする」で ある。 具体的には以下の4柱が満たられていることとされる。 - 退⾏(regression)に対する保護 - コードを変更した時のバグの発⾒しやすさ - コードの複雑さやビジネスとしての重要度も変数になる - リファクタリングへの耐性 - テストが失敗せずリファクタできる / コードが正しいのにテストが失敗することがない - 迅速なフィードバック - テストにかかる時間が短い - 保守のしやすさ - テストの読みやすさ / テストの実⾏のしやすさ 良いテストコード（ユニットテスト）
7. - MVPアーキテクチャ - Viewは、UI表⽰とUIの⼊出⼒ - Presenterは、画⾯ロジック - Modelは、ビジネスロジックやAPI, DBのデータ取得 - 2017年のアプリリニューアル時のアーキテクチャ Sansan Androidアプリのアーキテクチャ（⼀代⽬） Model View Presenter User event Request Update UI Result
8. - PresenterのテストにStub的なMockが多くて⾟い - Model-View間を繋いでいるので関わるクラスが多い - MockしているクラスのIFや実装を変えたとき、Mock側も対 応しなければならないのでMockが多いと⾟い - 状態管理の定義が曖昧 - Presenterで持つことも、Viewで持つことも - どこのテストに書かれているのか⾒つけにくい - PresenterやModelのクラスが⼤きくなりやすい - テストクラスも⼤きくなるので可読性が下がる MVP時代の課題（テストコード観点）
9. - 退⾏(regression)に対する保護 - そもそもバグを起こしやすい構造になっていた - リファクタリングへの耐性 - 低い - 迅速なフィードバック - 特筆すべきものはない - 保守のしやすさ - 可読性が低いため良くない 良いテストコードから考えると
10. アプリ開発の規模に アーキテクチャが合わなくなってきた
11. Sansan Androidアプリのアーキテクチャ（⼆代⽬） - Fluxアーキテクチャをベースに実装 - Fluxはmeta社が提唱した単⽅向データフローアーキテクチャ - Sansan Androidでは2019年から導⼊開始 よくインターネットで⾒る図↓ Action Dispatcher Store View Action
12. 実際のクラスの関係性 Sansan Androidアプリのアーキテクチャ（⼆代⽬） ActionCreator Action View Store Dispatcher generate Dispatch Action notify observe Dispatchされた Actionに応じて Stateを更新し保持する
13. - クラスの責務がMVPより明確になった - ActionCreator: Stateを変更するためのActionを作る。 Actionの作成に必要なRepositoryの関数も呼び出す。 - Store: Stateの保持。また、Actionの通知を受けてStateを更新 する。 - View: Storeの保持しているStateを購読し、画⾯表⽰する。 - 責務が明確なので、どんなテストがどこに書かれているかも想像 しやすい - それぞれのクラスが⼩さくなった Fluxになったことで解決した課題（テストコード観点）
14. - 責務が明確になり - 退⾏(regression)に対する保護 > 重要なロジックにテストを集中しやすくなった - リファクタリングへの耐性 > 余計なStubが減ったためリファクタしても壊れにくくなった - 迅速なフィードバック > テストを書くべきコードに焦点を当てやすく、余計なテス トがない = 全体の実⾏速度は早い - 保守のしやすさ > プロダクションコードもテストコードも書きやすくなった 良いテストコードから考えると
15. Flux時代(⼆代⽬アーキテクチャ)の課題 - StoreはActionを受け取り、必要に応じて現在のStateとActionを 合成して新しいStateを⽣成‧保持していた。 - ⼤規模な画⾯を開発するとActionが⾮常に多く、Storeが⼤きく なり可読性が下がる、テストが書きにくいなどの弊害が⽣じた。 - その後導⼊したJetpackComposeとStateが親和しない事が あった。また、画⾯ロジックが散逸し、統⼀性の喪失や、テスト が書きにくいなどの問題が⽣じた。
16. より開発⽣産性を上げるため 更に改良を⾏う
17. 実際のクラスの関係性（再掲） Sansan Androidアプリのアーキテクチャ（⼆代⽬） ActionCreator Action View Store Dispatcher generate Dispatch Action notify observe Dispatchされた Actionに応じて Stateを更新し保持する
18. 実際のクラスの関係性（新） Sansan Androidアプリのアーキテクチャ（⼆代⽬改） ActionCreator Action View Store Dispatcher generate Dispatch Action notify observe StateMachine ViewPropertyFactory ViewProperty create create state
19. ⼆代⽬アーキテクチャの課題の解決 - Fluxを少し拡張して、責務をさらに細分化 - 具体的には - Storeの役割から「Stateの⽣成」を分離 - 画⾯に直接バインドできる値を持つクラスを定義 > さらに⽣成ロジックも分離
20. - クラスの責務がさらに明確になり、よりテストしやすくなっ た - 各クラスの責務 - Store: Actionの通知を受け取る、Stateを保持する - StateMachine: 現在のStateと、Stateの更新に必要な情報 を受け取り新しいStateを返す - ViewPropertyFactory: Stateを元に、画⾯上で扱いやすい 形のオブジェクトを作る（ビューロジック） Flux(⼆代⽬改)で解決した課題（テストコード観点）
21. - さらに責務が細分化されることで - 退⾏(regression)に対する保護 > より重要なロジックにテストを集中しやすくなった - 迅速なフィードバック > より重要なテストに絞り込むことが出来た - 保守のしやすさ > さらにプロダクションコードもテストコードも書きやすく なった 良いテストコードから考えると
22. アーキテクチャが良くなると テストコードも良くなる
23. Sansanモバイルアプリに関わる「テスト」
24. - ユニットテスト - 各クラス‧関数をテストするコード - 基本的には書く⽅針 - PRを作るとCIで実⾏もされる（通らないとマージできない） - 結合テスト - 開発案件の終了間際、QAチームにより要件‧仕様を満たしている かどうかを⼿動テストする - リグレッションテスト - リリース前に既存機能にデグレが発⽣していないかをテストする - QAチームによる⼿動 + MagicPod Sansanモバイルアプリの「テスト」
25. - ユニットテストに求めているもの - その関数の正常系、異常系処理が期待通りの動きか > 前提、内容、結果を意識している(AAA) > 「正しく動くこと」と書くと怒られる > 仕様のドキュメント的な側⾯もある - リファクタリングの前後で関数の振る舞いが変わって ないことを確認できる Sansanモバイルアプリの「テスト」
26. - テストのカバレッジは明確には追ってない① - PRに2⼈のレビュアーからApproveを貰う必要がある > テストコードを全く書いてないと指摘される > StateMachineやViewPropertyFactoryのテストはまず 書かれる - リリース不具合が少ない > 前Qでリリースしたものでは⼤きな不具合なし > QAチームでの結合テストやリグレッションテストもある > 不具合検知率⾃体もテストケースに対して0.5%程度 （ケース数1803件に対して） Sansanモバイルアプリの「テスト」
27. - テストのカバレッジは明確には追ってない② - ほとんどの画⾯ではViewPropertyFactory, StateMachine の2つに対してテストコードを書いている > 全体に対しての網羅率は低いが、不具合は少なく抑え られている > 画⾯の状態に関するテストしたい重要な知識を持つ クラスを切り出してテストしやすくしている Sansanモバイルアプリの「テスト」
28. KMPに関するTips
29. KotlinMultiplatform - Sansanでは最近導⼊し始めた - iOS / AndroidのView以外の部分の共通化を図る - ビジネスロジックの共通化によりプラットフォームごと の仕様差異を減らす - リソースの効率化
30. - Androidで⼀般的なDagger/HiltはKMP未対応 - KoinがKMP環境では⼀般的なDIライブラリ - Hiltと違ってコンパイルエラーにならず、ランタイム クラッシュする - テストでのDIもサポートしているので、テストコードで DIの結果が期待通りであるかをチェックできる 期待通りDIされているかをテストで確認する
31. 勉強会やります
32. After Kotlin Fest 2024 LT Night ＠Sansan（LT登壇枠あり） - テーマ - Kotlinの内容であればなんでもOKのLT会 ▪ Kotlin 2.0の話も予定 - ⽇時 - 2024/07/08 19:00 - - 形式 - オンライン/オフライン併催
33. - テーマ - モバイルアプリ、モバイルアプリ開発関連ならなんでも ▪ iOS / Android問わず - ⽇時 - 2024/07/10 19:30 - - 形式 - オンライン/オフライン併催 Sansanモバイル勉強会 vol.1