Swiftでテスト時のみ『private』にアクセスする方法

mobile_stmn #1 で登壇した際の資料になります

Transcript

1. © Chatwork Swiftでテスト時のみ 『private』にアクセスする方法 2023年7月14日　モバイルアプリケーション開発部　中山 龍 Chatwork株式会社
2. 自己紹介 2 中山 龍 (なかやま りゅう) • Chatwork株式会社 ◦ モバイルアプリケーション開発部 ◦ iOSエンジニア ◦ 2023年4月 新卒として入社 ◦ 社内最年少 (2002年6月生まれの21歳) • 愛知県在住 ◦ フルリモート勤務 • 初めてのLTで緊張してます！ @ryu_develop
3. 3 © Chatwork はじめに
4. 4 テストを書いている時に...
5. 5 テストを書いている時に 『private』にアクセスしたいな って場面、ありませんか？
6. 例えば...テスト中に Privateな • 値をリセットしたい • 値を追いたい • メソッドをテストしたい 6 　　は避けた方が良い場合も...　　 終盤でお話しします
7. テストのためにprivateにアクセスしたいとき、どうすればいいんだろう？ 7
8. 今回扱う状況・問題 1
9. 今回想定する状況 9 class Sample { public static let shared = Sample() private var value = 0 } • privateなプロパティ『value』を持っているclass • シングルトン
10. このclassをテストする際の問題点 10 • classをテストごとにインスタンス化ができない → 🚨 シングルトンならではの問題が起きる
11. このclassをテストする際の問題点 11 • classをテストごとにインスタンス化ができない • privateなプロパティをテストごとにリセットできず、値がテ ストを超えて引き継がれてしまう → 🚨 シングルトンならではの問題が起きる
12. このclassをテストする際の問題点 12 • classをテストごとにインスタンス化ができない • privateなプロパティをテストごとにリセットできず、値がテ ストを超えて引き継がれてしまう → テストの結果が実行順に左右されてしまう 🚨 シングルトンならではの問題が起きる
13. 13 変更した値が次のテストにも引き継 がれるのを回避したい
14. 14 『private』なプロパティにアクセス して、値をリセットしたい
15. 何も考えずに『private』にアクセスするとしたら？ 2
16. class Sample { public static let shared = Sample() private var value = 0 func getter() -> Int { return value } func setter(value: Int) { self.value = value } } 何も考えずに『private』にアクセスするとしたら 16 getterとsetterを持たせる ↓ privateへのget / set が可能 になる
17. 17 アクセスできるけど... これだとprivateにした意味がない！ テストの時だけgetterとsetterを使える ようにできないでしょうか？
18. 『テスト』を判定してアクセスを可能にする 3
19. 『テスト』のビルドを判定する 19 iOS開発ではビルドの種類を判定する仕組みがある #if DEBUG // デバッグ時の処理 #endif 以下は、「デバッグビルドの際に処理が走る」という例 デバッグ ビルド デバッグ時 の処理 YES NO
20. 『テスト』のビルドを判定する 20 この分岐は「Build Configuration」によって 判定されている デフォルトで存在するBuild Configurationは • Debug • Release の2種類
21. 『テスト』のビルドを判定する 21 この「Build Configuration」に「Test」を追加すれば、 「テスト」のビルドを判定できるのではないか？
22. 『Build Configuration』を追加する(手順解説) 4
23. Build Configurationの追加方法 23 PROJECT 内の Info で Configurations左下の+ をクリック し、Duplicate “Debug” Configurationを選択 生成されたものの名前をTestにする 1.
24. Build Configurationの追加方法 24 Edit Schemeを開き、TestのBuild ConfigurationでTestを 選択する 2.
25. Build Configurationの追加方法 25 PROJECT の Build Settings にある Active Compilation Conditions で Testキー の値を TESTにする 3.
26. 26 こうすることでBuild Configurationが追加され、 #if TESTで「テスト」を判定できるようになる
27. 実際に分岐させる 5
28. class Sample { public static let shared = Sample() private var value = 0 #if TEST func getter() -> Int { return value } func setter(value: Int) { self.value = value } #endif } テストで分岐させてみる 28 getterとsetterを #if TEST 〜 #endifで囲むと、 テスト以外では存在しないこと にできる
29. つまり 29 class Sample { public static let shared = Sample() private var value = 0 func getter() -> Int { return value } func setter(value: Int) { self.value = value } } テストビルド時 class Sample { public static let shared = Sample() private var value = 0 } テスト以外のビルド時 テストビルド以外の際にはgetter とsetterが無い扱いとなる
30. 30 通常時はprivateのメリットを生かしつつ、 テストの時には『private』にアクセス できるようになった！！
31. 補足 31 「#if TEST」で囲まれた部分を呼び出すコードを書くと Xcodeに警告される。 それは、おそらく静的解析がテストビルド以外の Configurationで走っているためである。(予想) 警告を無視しても問題なくビルドできる
32. 他にも... 32 この#if TEST 〜 #endifの書き方を応用すること で、テスト内で自由に『private』にアクセスした り、テスト時のDIに活用したりすることができる
33. 33 でも...注意する点があります
34. テストで『private』にアクセスする際の注意 6
35. 注意点 35 冒頭でも少しお話ししたようにprivateに対するテストは避 けた方が良い場合もあります
36. 注意点 36 自動テストを書く理由の一つとして「リファクタリングの支えになる」という点があ ります • リファクタリング：「外部から見た振る舞いを変えずに内部の実装をきれいにするこ と」 t-wadaさんのブログ: プライベートメソッドのテストは書かないもの？ より引用し、要約 https://t-wada.hatenablog.jp/entry/should-we-test-private-methods
37. 注意点 37 自動テストを書く理由の一つとして「リファクタリングの支えになる」という点があ ります • リファクタリング：「外部から見た振る舞いを変えずに内部の実装をきれいにするこ と」 しかし、privateに対するテストは「内部の実装に対するテスト」になってしまうこ とが多い → リファクタリングの妨げになりがち t-wadaさんのブログ: プライベートメソッドのテストは書かないもの？ より引用し、要約 https://t-wada.hatenablog.jp/entry/should-we-test-private-methods
38. 注意点 38 privateに対してのテストを書いてしまうと 自動テストで積極的にリファクタリングを行いたい ↓ 自動テストがリファクタリングの妨げになる という場合も... → テスト時に『private』にアクセスする場合は、この ような状況に気をつけましょう
39. まとめ 7
40. まとめ 40 • Build Configurationを追加することで、テストのビルドを判 定して、適切な処理の分岐が可能になる ◦ 今回紹介した方法で 「#if TEST」 が使えるようになる
41. まとめ 41 • #if TESTが使えると... ◦ 通常ビルドではprivateの恩恵を受けつつ、テスト時には privateにアクセスして、値のリセットなどができる ◦ テスト用にDIをする処理を書くなど、使い方によって様々 なことが可能になる
42. まとめ 42 • ただし、privateに対してテストを書く・値を操作する時には、 それがリファクタリングの妨げにならないように気をつける
43. 働くをもっと楽しく、創造的に