少しずつ手厚くして不具合や仕様漏れを防ぐために
•
0 j'aime•1,630 vues
開発×テスト LT会 - vol.2 #devtestltでの登壇資料になります。 簡単なテストコードに関するおさらいから、iOSアプリ内部での処理事例を元にした、意外と気が付きにくい観点やコードを読むだけでは振る舞いが見抜きにくい処理に関するテストの事例も簡単に紹介したものになります。 （この資料にて紹介されているコードはRxSwift & Quick & Nimble & SwiftyMockyを利用したものになります）
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 少しずつ手厚くして不具合や仕様漏れを防ぐために
Similaire à 少しずつ手厚くして不具合や仕様漏れを防ぐために (20)
Plus de Fumiya Sakai
Plus de Fumiya Sakai (20)
Dernier
Dernier (14)
少しずつ手厚くして不具合や仕様漏れを防ぐために
- 5. 今回の処理で想定している責務レイヤーの分割例 ここではRxSwiftを利用したPresenter ⇄ UseCase ⇄ Repositoryの処理 Presentation Business Logic Domain Logic Infrastructure - DomainModel (Entity) - Repository - DomainService - RestAPI Client - GraphQL Client - UserDefault / Realm - View (ViewController) - Presenter - Contract RxSwiftでのOperatorを利用する (Single / Maybe / Completable) FirebaseRemoteConfigClient // sourcery: AutoMockable protocol FirebaseRemoteConfigClient { func getFeaturedRecipes() -> Single<[FeaturedRecipeEntityJson]> func getFeaturedRecipeEnabled() -> Single<Bool> func getTrendKeywords() -> Single<[TrendKeywordEntityJson]> func getTrendKeywordEnabled() -> Single<Bool> … (get display data and feature flags) … } UseCase // sourcery: AutoMockable protocol CheckTrendKeywordEnabledUseCase { func execute() -> Single<Bool> } // sourcery: AutoMockable protocol GetTrendKeywordUseCase { func execute() -> Single<[TrendKeyword]> } 例1. A/Bテスト (Optional) 例2. 表示データ取得処理 - return Single<Bool> - Fetch from Remote Config - Convert to DomainModel - UseCase
- 6. 並列 Quick + Nimble + SwiftyMockyを組み合わせた形(1) RxBlockingを利用しつつもUnitTestの骨格部分はQuick + Nimbleの組み合わせ テストケースの基本形 全体処理を考える describe("#execute") { context(“A/Bの対象＆トレンドキーワードの一覧が取得処理が成功した場合”) { let checkTrendKeywordEnabled = true let trendkeywords = … (Stubに相当するテストデータの作成) … beforeEach { checkTrendKeywordEnabledUseCase.given( .execute(willReturn: Single.just(checkTrendKeywordEnabled)) ) getTrendKeywordUseCase.given( .execute(willReturn: Single.just(trendkeywords)) ) } it(“トレンドキーワードのデータ一覧が取得できること”) { expect(try! target.fetch().toBlocking().first()) .to(equal(trendkeywords)) } } } ① Quick & Nimbleの記載方法 ② Stubを定義してMockに適用する - ① Business Logic → return Single<P> - ② Another Business Logic → return Single<Q> - ③ Common Business Logic → return Single<R> Expected Result → return S とある処理でこの3つの処理が必要になる場合： (Point) 実際のコードで結果を得るための処理は？ ③ 期待するケースをRxBlockingを利用して記載 ① Single<P> ② Single<Q> ③ Single<R> ① Single<P> → ② Single<Q> → ③ Single<R> 直列 ※ 処理の順番が実は大きな影響を及ぼす場合もあったりする
- 7. Quick + Nimble + SwiftyMockyを組み合わせた形(2) SwiftyMockyを利用して該当する責務部分をUnitTestで利用するためにMock化 SwiftyMockyの導入と紹介 // Install SwiftyMocky CLI $ brew install mint $ mint install MakeAWishFoundation/SwiftyMocky 👉 Swift Package Manager 👉 Test Target // MEMO: Mock preparation required for testing let checkTrendKeywordEnabledUseCase = CheckTrendKeywordEnabledUseCaseMock() let getTrendKeywordUseCase = GetTrendKeywordUseCaseMock() // MEMO: Apply Mock to the class under test let target = TrendKeywordPresenterImpl( checkTrendKeywordEnabledUseCase: checkTrendKeywordEnabledUseCase, getTrendKeywordUseCase: getTrendKeywordUseCase ) // sourcery: AutoMockable protocol CheckTrendKeywordEnabledUseCase { func execute() -> Single<Bool> } // sourcery: AutoMockable protocol GetTrendKeywordUseCase { func execute() -> Single<[TrendKeyword]> } // Generate Mock $ swiftymocky generate UnitTestを実施する準備 SwiftyMocky： https://github.com/MakeAWishFoundation/SwiftyMocky Mockを適用して想定する値を返す形を作っていく
- 8. 仕様で本当に抜け漏れがないか(MECEか?)を確認する できれば細かな画面の振る舞いに関する部分まで想定すると良いかもしれない A/Bテスト対象時のみ表示 History: keyword ← salad chicken sushi × × × Trend: A/Bテスト対象か否かで変化 - A/Bテストが対象ならばこのセクションを表示する - A/Bテストが対象でないならばセクション自体を表示しない (Point) ここから更に深ぼって読み取ると更に細かな仕様はどうなるか - A/Bテストの対象ではあるが、もしこの場合にトレンドキーワードが1つもない場合はどうする？ - A/Bテスト処理 or トレンドキーワード取得処理のいずれか1つがエラーだった場合はどうする？ - エラーになってしまった際の対象部分以外の画面表示についてはどうする？ 🤔 本当にこれで大丈夫か？ 足りない要件はないか？ 検索画面の中にトレンドキーワードを表示したい：
- 9. 先ほどの処理の一例（どこまでをエラーとするか？） ここではA/Bテストの対象かが不明だった場合には後続の処理は続ける方針 Presentation部分の処理例 checkTrendKeywordEnabledUseCase.execute() .observe(on: mainScheduler) .subscribe( onSuccess: { [weak self] checkTrendKeywordEnabled in guard let weakSelf = self else { return } weakSelf.fetchTrendKeywords( checkTrendKeywordEnabled: checkTrendKeywordEnabled ) }, onFailure: { [weak self] _ in weakSelf.fetchTrendKeywords( checkTrendKeywordEnabled: false ) } ) .disposed(by: disposeBag) private func fetchTrendKeywords(checkTrendKeywordEnabled: Bool) { getTrendKeywordUseCase.execute() .observe(on: mainScheduler) .subscribe( onSuccess: { [weak self] trendKeywords in guard let weakSelf = self else { return } let souldHide = trendKeywords.isEmpty || !checkTrendKeywordEnabled weakSelf.view?.setup(trendKeywords: souldHide ? trendKeywords : []) }, onFailure: { [weak self] _ in guard let weakSelf = self else { return } weakSelf.view?.showError(error: error, closeHandler: {}) } ) .disposed(by: disposeBag) } ① まずはA/Bの対象かを確認 ② トレンドキーワードを表示する ③ キーワード一覧を失敗した場合のみ
- 10. 言葉だとシンプルだが実際に正しいかすぐに解らない 1つ1つの条件自体はシンプルであったとしても組み合わせると複雑になる場合 Carouselバナー表示部分 Shop List: お店を探す Special Contents: 表示データの並び順の条件 - 表示データにはID(Unique) / 優先度 / 日付の項目がある - 条件は、優先度の値が小さい > 日付が若い > IDが若い順 (Point) 処理よりも実現するためのテストケースの作り方が重要そうだ - 条件となるものが複数存在する、かつ複合な条件である。 - IDはユニークな値でも日付や優先度については運用の都合で等しい値の可能性がありえる。 - 登録されているデータについてもバックエンド側で順番を担保してくれないとしたら？ 🤔 目視では見誤りそうだ。 UnitTestで担保したいな。 Carouselバナー5件表示部分の並ぶ順を決める：
- 11. 先ほどの処理の一例（シンプルに書けたけど…） 処理自体は数行でさっと収まるような分量ではあるがわかりにくさもある 該当UseCase部分の処理例 private func getSpecialContentBanners() -> Single<[SpecialContentBanner]> { return specialContentsBannerRepository.findAll() .flatMap { specialContentsBanners in let targetSpecialContentsBanners = specialContentsBanners .sorted { ($0.priority, $0.date, $0.id.value) < ($1.priority, $1.date, $1.id.value) } .prefix(5) return Single.just(targetSpecialContentsBanners) } } データを全件を取得後にSortを実施 「優先度の値が小さい > 日付が若い > IDが若い」順 - 例1. 日付が全て等しい & 優先度が全て等しい → IDの順番でデータが取得できていること - 例2. 日付が全て等しい & スペシャルコンテンツバナー優先度がIDの並び順と異なる → 優先度とIDを加味した順番となること - 例3. 日付が異なる & スペシャルコンテンツバナー優先度もIDの並び順と異なる → 日付・優先度・IDを加味した順番となること cf. tuple利用した複数の設定をしています。 ぱっと見だと結構わかりにくいので具体的なテストケースを準備する例：
- 12. データの表示順番や並べ替え処理が重要になる場合 題意を満たすことができる様なテストデータを作成してUnitTestで担保する 検証用スタブデータ例 実際のテストケース事例 let banner1 = SpecialContentsBannerTestData( id: 1, priority: 3, date: nowDate ) let banner2 = SpecialContentsBannerTestData( id: 2, priority: 1, date: twoDayLaterDate ) let banner3 = SpecialContentsBannerTestData( id: 3, priority: 1, date: threeDayLaterDate ) let banner4 = SpecialContentsBannerTestData( id: 4, priority: 1, date: twoDayLaterDate ) let banner5 = SpecialContentsBannerTestData( id: 5, priority: 2, date: twoDayLaterDate ) let banner6 = SpecialContentsBannerTestData( id: 6, priority: 2, date: twoDayLaterDate ) context("順番が正しくソートできているかのテスト") { beforeEach { specialContentsBannerRepository.given( .findAll( willReturn: Single.just([banner1, banner2, … banner6]) ) ) } it("IDが2,4,3,5,6の順番にbannerが5件取得できること") { let actual = sut.execute() let expected = [banner2, banner4, banner3, banner5, banner6] expect(try! actual.toBlocking().first()).to(equal(expected)) } } 日付を微妙に ずらしたデータ ② 期待する順番と一致するかを判定 ① Mockでは全データを返す想定
- 13. 実は細かな点に気を配ってみると疑問が生まれる処理 厳密に考えるとデータがないケースについても考えておきたいと思う場合 おすすめ or 関連を表示する Related or Recommend: ○○○のお店 レスポンス取得タイミングの状態を考慮する - 関連のお店が取得できた時はそのまま表示する - 関連のお店が取得失敗時にはおすすめを取得を試みる (Point) 画面になにも表示しない場合を考えてみると良いかもしれない - 関連のお店が取得できたがお店データが0件となってしまった場合はどう扱う？ - 関連のお店が失敗し、おすすめが取得できたがお店データが0件の場合はどう扱う？ - 画面としてエラー表示をさせる場合は共に失敗した時だけで良いのか？ 🤔 そのままSingle.zipは🙅 ならばどんな形にしようか 詳細画面内においておすすめ or 関連を表示：
- 14. 先ほどの処理の一例（どの場合を全体エラーとする？） 処理全体としてのエラーとみなすタイミングをどこに置くかに注目する 該当UseCase部分の処理例 private func getRelatedOrRecommendedCourses(shopId: ShopId) -> Single<RelatedOrRecommendedShopsDto> { return shopRepository.findAllRelatedById(shopId) .flatMap { [weak self] relatedShops in guard let weakSelf = self else { return Single.error(CommonError.notExistSelf) } return weakSelf.getDtoByRelatedShops(relatedshops: relatedShops) } .catch { [weak self] _ in guard let weakSelf = self else { return Single.error(CommonError.notExistSelf) } return weakSelf.getDtoByRecommendedShops() } } ① 0件/Error発生時は.catch内の処理 後続処理を続けるための工夫： // MEMO: findAllRelatedByIdでの結果が空の場合はエラー if relatedShops.isEmpty { return Single.error(GlobisError.notExistObject) } 👉 成功時は必要なObject(Dto)を返却する ② 0件/Error発生時は全体のエラー 👉 成功時は必要なObject(Dto)を返却する RxSwiftの.catchを利用することで最初の処理がエラーとなっても次の処理を実行させる
- 15. 責務全体と単一処理のエラーハンドリングを加味する 全体のエラーとみなす場合とそうでない場合のUnitTestで仕様を担保する 実際のテストケース事例 その他のテストケース洗い出し例 context("ショップに紐づく関連ショップ・おすすめショップの両方が存在する場合") { beforeEach { shopRepository.given( .findAllRelatedById(.value(shopId), willReturn: Single.just(relatedShops)) ) shopRepository.given( .findRecommended(willReturn: Single.just(recommendShops)) ) } it("関連ショップが格納されたRelatedOrRecommendedShopsDtoが返る") { let single = target.execute(shopId: shopId) let expected = RelatedOrRecommendedShopsDto( relatedShops: expectedRelatedShops, recommendedShops: [] ) let actual = try! single.toBlocking().first() expect(actual).to(equal(expected)) } } ② 関連ショップが優先される ① 関連＆おすすめがともに正常 関連1件以上 && おすすめ0件： - ⭕ 関連ショップ一覧表示 関連0件 && おすすめ1件以上： - ⭕ おすすめショップ一覧表示 関連0件 && おすすめ0件： - ⭕ 全体エラー表示 関連1件以上 && おすすめError： 関連0件 && おすすめError： 関連Error && おすすめ1件以上： 関連Error && おすすめ0件：
- 17. 過去にUnitTestを利用したことで助けられた事例 最初は自分も見様見真似から、出来る所から初めて、危ない所を徐々に厚く 📊 Qiita (Article): 📊 Library (Github): 個人開発及び実務でユニットテストに助けられたと 個人的に感じた例の紹介： https://qiita.com/fumiyasac@github/items/19c525116f1b585bb43f handMadeCalendarAdvance 2000年以降の日本の祝祭日を判定するライブラリ： https://github.com/fumiyasac/handMadeCalendarAdvance