開発作業やテストの時にMockでケースごとの UIチェックやテストを書きやすくする

1. 開発作業やテストの時にMockでケースごとの
UIチェックやテストを書きやすくする
POTATOTIPS #73 2021/03/26
@MedPeer, Inc.
杉山 優悟

2. README
• Name: 杉山優悟 / Yugo Sugiyama
• Age: 27歳
• From: 神奈川県藤沢市
• Job: SHOWROOM株式会社(2020/4/16 )
• Hobby: 料理、アニメ、自転車、テニス
• Quali
fi
cation: 教員免許(中学/高等学校社会科全般)

3. 今日の発表内容
開発作業やテストの時にMockでケースごと
のUIチェックやテストを書きやすくする

4. 開発やテストを書く時に困ること
• APIができてなくて、API通信ができない
• リストが複数、1つ、空など複数のユースケースのUIチェック用の
データの用意が大変
• 上記のようなユースケースのUIを個別にすぐ確認するのが難しい
• 上記のようなユースケースのテストコードを網羅的に書くのが難しい

5. １つの改善案として
• DIを使って、ユースケースごとのデータが返るような実装を用意
1. Dependency Injectionを使って、通信処理のAPI用/Mock用の
Classを切り替えられるようにする。
2. ユースケース分のMockTypeを事前に定義しておき、DebugMenu
からそれらを切り替えられるようにする。
3. MockのClassは設定したMockTypeに応じた値を返すようにする。

6. デモ

7. 1. Dependency Injectionを使って、通信処理のAPI
用/Mock用のClassを切り替えられるようにする。
• API接続用のクラスとMock用のclassをDIを使って、切り替えられるようにする
• デモアプリでは、DIContainerとしてDependenciesをベースして、以下のように
使ってます。
• @Injectと型をつけると、DIContainerに設定したインスタンスを参照できる
• 参照を持っているだけなので、DebugMenuなどからインスタンスを切り替えるこ
とができる。
@Inject private var mockService: MockProtocol

8. 2. 動作パターン分のMockTypeを事前に定義しておき、
DebugMenuからそれらを切り替えられるようにする。
• 以下のようなMockTypeのenumを定義
• DebugMenuから選択中のMockTypeを切り替えて、UserDefaultsに保存する
• UserDefaultsの状態に合わせて、通信用classを再設定する
enum MockType: String, CaseIterable {
case randomList
case randomListWithSameColor
case randomListWithShortText
case randomListWithDelay
case single
case empty
case error
}

9. 3. MockのClassは設定したMockTypeに応じた
値を返すようにする。
• 選択したMockTypeに応じて、レスポンスを切り替える
switch mockType {
case .randomList:
let list = [Int](0...Int.random(in: 1...100))
.map({ _ in ColorModel(text: .random(), color: .random) })
completion(.success(list))
case .single:
completion(.success([.init(text: .random(), color: .random)]))
case .empty:
completion(.success([]))
case .error:
completion(.failure(MockError.mockError(message: "This is Error(Mock)”)))
……
}

10. Mock切り替えのメリット
• APIの実装前でも開発できる。
• テストが(個人的には)書きやすい
• ユースケースごとのUIチェック・テストケースを網羅的にかける
• MockTypeごとのテストを作成する
• ユースケースが増減しても、追加・削除が容易
• InHouseなど配布用のアプリ(端末のみ)でも検証可能

11. Mock切り替えのデメリット
• MockTypeやMockクラスの処理を仕様通りに書かないと意味がない
• 当たり前ですが。。
• API通信(URLRequestなど)やDecodableなどjsonのparse処理の動作確認やテス
トはできない
• Charles使って動作確認したり、別途Parse用のテストなどは書く必要がある
• 最初の準備は少し大変
• その後の横展開はそこまで手間ではない

12. 結論
開発作業やテストの時の作業がしやすいよ
うな環境を整えることは大事

13. 終劇

14. 予告

15. 次回
終わるRx、始まるCombine(仮)