「swift-testingはじめました」 Quick/Nimbleからの置き換えの最初の一歩

potatotips#88での登壇資料になります。

WWDC2024で「swift-testing」に関するセッションが公開されていた経緯や、同僚が個人開発で利用していた事から関心を持ち、自分が携わるiOSプロジェクト内でも導入してみる前段の調査内容をまとめた資料になります。

自分もこれまではQuick/Nimbleを活用してUnitTestを記載した経験の方が長かったです。元々Rails等にも触れた経験もあったのでRSpecに近い形には慣れていた事もありましたが、この機会にできる所から徐々に書き換えにトライしてみました。

そもそもの書き方が変化する事は想定できましたが、取り組み始めた際に「実はこの部分が少し苦労した」という点をご紹介できればと考えています。
（※今回は元々のコードを愚直に置き換える場合を想定しています）

Transcript

1. 「swift-testingはじめました」 Quick/Nimbleからの置き換えの最初の一歩 potatotips #88 @ STORES様 2024/07/05 Fumiya Sakai
2. 自己紹介 ・Fumiya Sakai ・Mobile Application Engineer アカウント: ・Twitter: https://twitter.com/fumiyasac ・Facebook: https://www.facebook.com/fumiya.sakai.37 ・Github: https://github.com/fumiyasac ・Qiita: https://qiita.com/fumiyasac@github 発表者: ・Born on September 21, 1984 これまでの歩み: Web Designer 2008 ~ 2010 Web Engineer 2012 ~ 2016 App Engineer 2017 ~ Now iOS / Android / sometimes Flutter
3. iOSのUI実装本を執筆しています！ 書籍に掲載したサンプルのバージョンアップや続編等に現在着手中です。 少しの工夫で実現できるTIPS集やライブラリ表現の活用集をはじめとした、iOSア プリ開発の中でも特にUI実装やUIKitを利用した画面の中で特徴を与える様な表現 という題材に焦点を当てた書籍となっております。 現在は電子書籍版のみとなります。 こちらは全て¥1,000となっております。 https://just1factory.booth.pm/ 概要: https://book-tech.com/ 価格: 📖 Booth 📖 Book Tech
4. UI実装であると嬉しいレシピブックの最新情報 UI実装であると嬉しいレシピブックVol.3として昨年10月に商業化しました！ Still WIP これまでの同人誌として頒布したものに加えて、Vol.1及びVol.2に頒布したものの 中で書籍に載せきれなかったものや表現や動きが特徴的でユーザーにもほんの少し 遊び心を与える様なUI実装を紹介したものをVol.3としています。 概要: これからの構想: こちらで購入可能です: Amazon / Google Play / Apple Books / KINOKUNIYA / Rakuten BOOKS etc.. 🏊 iOS: SwiftUIを利用したUI実装や動画関連の実装 🏊 Android: Jetpack Composeの基本やその他気になるUI表現の考察
5. (告知) iOSDC Japan 2024へ原稿を2つ寄稿しています！ Combineベースの実装をSwift Concurrencyへ少しずつ 置き換えていく際のアイデアとヒントのご紹介 UIKitを利用した複雑な表現を SwiftUIで再現する際の考え方と事例紹介
6. 自分が携わるiOSプロジェクト内で始めて導入してみました 最初は試験的な導入ではありますが現在も本格利用すべく試行錯誤中です。 まずは「swift-testing」を利用する事に加えて、既存UnitTestを置き換える事に焦点を当てています。 1. Combineを利用した形であっても「swift-testing」を利用したUnitTestを試してみる： async/awaitをこれから本格的に導入を試していく中で、まずは「swift-testing」に触れながら、試していこうと感じました。 またWWDC2024の発表で正式に追加された発表があった事により、今後はこちらをより利用できるのでは？と感じました。 2. 元々は使い慣れたQuick/Nimbleを利用した形のUnitTestを利用していました： 自分もこれまではQuick/Nimbleを活用してUnitTestを記載した経験の方が長かったです。元々Rails等にも触れた経験もあったの でRSpecに近い形には慣れていた事もありましたが、この機会にできる所から徐々に書き換えにトライしてみました。 3. Quick/Nimbleからの書き換えを試した際の所感について： そもそもの書き方が変化する事は想定できましたが、取り組み始めた際に「実はこの部分が少し苦労した」という点をご紹介で きればと考えています。（※今回は元々のコードを愚直に置き換える場合を想定しています）
7. 「swift-testing」に関連する基本事項を確認する Swift5.9から利用可能＆UnitTestに関する新たな進化を感じています。 WWDC2024公開動画： https://developer.apple.com/videos/play/wwdc2024/10179 Meet Swift Testing: https://developer.apple.com/videos/play/wwdc2024/10195 Go further with Swift Testing: 公式リポジトリ： https://github.com/apple/swift-testing swift-testing Repository: 公式ドキュメント： https://developer.apple.com/documentation/Testing Swift Testing:
8. Combine＆Quick/Nimbleの構成からの移行にトライ そのままではCombineのUnitTestがしづらいので、その点を上手く補う Combineを利用したUnitTestを便利にするライブラリ： https://github.com/groue/CombineExpectations CombineExpectations: https://github.com/pointfreeco/combine-schedulers combine-schedulers: 今後の展望： 1. Combine処理は今後async/awaitへ置き換えていく予定 2. Quick/Nimbleで元々記述されているUnitTestも置換する予定 参考: iOSDC Japan 2023の原稿内容 https://github.com/fumiyasac/iosdc2023_pamphlet_manuscript_vol2 Publisherで流れてくる値の履歴を取得可能にする 3. Combine処理を補うライブラリ依存も徐々に減らしてく予定
9. 簡単なViewModel処理例とQuick/NimbleでのUnitTest(1) シンプルな処理をする様なViewModelの事例とUnitTestを考えてみます final class NewsViewModel: ObservableObject // MEMO: APIリクエストを実行してお知らせデータ一覧の取得をするメソッド func fetchNewsItems() { api.getNewsItems() .sink(receiveCompletion: { completion in switch completion { case .finished: // MEMO: APIから値取得処理が「成功」した際に実行される部分 case .failure(let error): // MEMO: APIから値取得処理が「失敗」した際に実行される部分 } }, receiveValue: { [weak self] hashableObjects in // 👉 お知らせデータ一覧が取得できた場合 // SwiftUI側でも利用する`@Published`で定義した変数へ反映する self?.newsItem = hashableObjects }) .store(in: &cancellables) } } private let api: APIRequestManagerProtocol private var cancellables: [AnyCancellable] = [] // MARK: - NewsViewModelOutputs // 👉 `@Published`で定義した変数をそのままOutputとして利用する // (1) SwiftUI製のView要素に直接Bindして利用する場合もあります。 // (2) アクセス修飾子はBindするSwiftUI要素に合わせて変更する場合もあります。 // ※この値を利用した「Computed Property」を別途定義して利用する場合もあります。 @Published private(set) var newsItem: [NewsItem] = [] // MARK: - Initializer init(api: APIRequestManagerProtocol) { // MEMO: 適用するAPIリクエスト用の処理 self.api = api } APIからニュース一覧情報を取得する様な想定：
10. 簡単なViewModel処理例とQuick/NimbleでのUnitTest(2) シンプルな処理をする様なViewModelの事例とUnitTestを考えてみます Quick/Nimbleを利用したUnitTest例： describe("#fetchNewsItems") { // 期待する初期値 & 実行後に期待する値を定義する let emptyItems: [NewsItem] = [] let expectedNextItems: [NewsItem] = [ NewsItem(id: 1, title: "夏祭り2023開催のお知らせ", category: "イベント"), NewsItem(id: 2, title: "美味しい餃子の販売開始", category: "新商品"), NewsItem(id: 3, title: "美味しいプリンの販売開始", category: "新商品") ] // 👉 NewsViewModelをインスタンス化する際に、想定するAPIリクエストのMockを適用 // ※補足: func getNewsItems() -> AnyPublisher<[NewsItem], Never> を想定 let sut = NewsViewModel(api: APIRequestManagerMock()) // CombineExpectationを利用してViewModel内の変数:newsItemの変化を記録する想定 // 👉 変数:newsItemで`@Published`を利用するのでこの値変化を記録対象とする var newsItemsRecorder: Recorder<[NewsItem], Never>! // context 〜 it の流れで検証したいケースを作成する } context("API通信処理が成功した場合") { // 👉 UnitTest実行前後で実行する処理 beforeEach { newsItemsRecorder = sut.$newsItem.record() } afterEach { newsItemsRecorder = nil } // 値変化を記録対象とする変数が、期待した変化をすること確認する it("初期値:emptyItemsの内容 → 実行後:expectedNextItems となること") { // 👉 ViewModel内処理を実行 sut.fetchNewsItems() // 0.16秒間の変化を見て、期待した値変化となることを確認する let newsItemsRecorderResult = try! self.current .wait(for: newsItemsRecorder.availableElements, timeout: 0.16) expect(newsItemsRecorderResult) .to(equal([emptyItems, expectedNextItems])) } } final class NewsViewModelTest: QuickSpec
11. こちらを「swift-testing」で書き直す時はどうする？ シンプルなテストケースからまずは「形」を素直に作ってみる所から始める ①基本の形を見比べてみる 既存のQuick/Nimbleでの記述と比べ て具体的に何がどう変化するのか？ ②Matcher処理部分 使い慣れたMatcherとの類似点・相 違点はあるか？ ③テストケース記述の変化 テスト自体を一目でわかり易い形す る工夫（given/when/thenの形）。 （注意）Xcode15で動作させる場合： import XCTest import Testing final class AllTests: XCTestCase { func testAll() async { await XCTestScaffold.runAllTests(hostedBy: self) } } Xcode15で「swift-testing」を利用する際にはこの記述が必要になる。 段階的に少しずつ置き換えていく想定をした場合なのと自分がまだお試し段階なのでまずは置き換えに注目 ※ swift-testingとXCTestは共存する事が可能
12. 実際に前述したCombineのテストを書き換えてみる swift-testingとCombineExpectationsの利用でも何とかできそうでした // 期待する初期値 & 実行後に期待する値を定義する let emptyItems: [NewsItem] = [] let expectedNextItems: [NewsItem] = [ NewsItem(id: 1, title: "夏祭り2023開催のお知らせ", category: "イベント"), NewsItem(id: 2, title: "美味しい餃子の販売開始", category: "新商品"), NewsItem(id: 3, title: "美味しいプリンの販売開始", category: "新商品") ] // 👉 NewsViewModelをインスタンス化する際に、想定するAPIリクエストのMockを適用する // ※補足: func getNewsItems() -> AnyPublisher<[NewsItem], Never> を想定 let sut = NewsViewModel(api: APIRequestManagerMock()) // CombineExpectationを利用してViewModel内の変数:newsItemの変化を記録するようにしたい // 👉 変数:newsItemで`@Published`を利用しているのでこの値変化を記録対象とする var newsItemsRecorder: Recorder<[NewsItem], Never>! @Test @MainActor func fetchNewsItemsSuccess() throws { // 👉 ViewModel内処理を実行 sut.fetchNewsItems() // 👉 変数:newsItemが変化した記録を確認する // (1) availableElements.get()を利用して内容を取得する let newsItemsRecorderResult = try newsItemsRecorder.availableElements.get() // (2) 変化の内容がArrayで記録されていること // 初期値:emptyItems → 実行後:expectedNextItems #expect(newsItemsRecorderResult == [emptyItems, expectedNextItems]) } swift-testingを使って（強引に）書き換えた例： @Suite final class NewsViewModelTest init() { newsItemsRecorder = sut.$newsItem.record() } deinit { newsItemsRecorder = nil } UnitTestに必要なProperty定義群 UnitTestの本丸になる部分はここ @Suite class (or struct or actor) ~ @Test func … の様な形を取ります
13. Quick/Nimbleからswift-testingへ書き換えのヒント(1) 両方のドキュメントから基本形は結構似ている点がありそうだという所感 私はこの様な感じになるかな？と考えました： Quick / Nimble 利用時 swift-testing 利用時 final class NewsViewModelTest: QuickSpec @Suite final class NewsViewModelTest init() { … } deinit { … } describe("#fetchNewsItems") { … context("API通信処理が成功した場合") { … it("初期値:emptyItemsの内容 → 実行後:expectedNextItems") { … } } } beforeEach { … } afterEach { … } @Test @MainActor func fetchNewsItemsSuccess() throws { … } 事前準備・後始末 事前準備・後始末 ① describeを入れ子にする際は@Suite内にクラスや構造体を準備 UnitTestを構築する際のポイント: ② テストに必要な変数・Mock・Stub等を定義する点は似ている ※(describe) or (context)に該当する
14. Quick/Nimbleからswift-testingへ書き換えのヒント(2) 検証項目自体の組み立てはそれ程大きな変化はなくMatcherも使いやすくなった itに該当する部分はそれ程変化はない＆Matcherはシンプル（より複雑なテストで要検証）： Quick / Nimble 利用時 swift-testing 利用時 final class NewsViewModelTest: QuickSpec @Suite final class NewsViewModelTest // 👉 ViewModel内処理を実行 sut.fetchNewsItems() // 👉 変数:newsItemが変化した記録を確認する // (1) availableElements.get()を利用して内容を取得する let newsItemsRecorderResult = try! self.current.wait( for: newsItemsRecorder.availableElements, timeout: 0.16) // (2) 変化の内容がArrayで記録されていること // 初期値:emptyItems → 実行後:expectedNextItems expect(newsItemsRecorderResult).to(equal([emptyItems, expectedNextItems])) // ※重要※ @MainActor内でこのテストを実行 // 👉 ViewModel内処理を実行 sut.fetchNewsItems() // 👉 変数:newsItemが変化した記録を確認する // (1) availableElements.get()を利用して内容を取得する let newsItemsRecorderResult = try newsItemsRecorder.availableElements.get() // (2) 変化の内容がArrayで記録されていること // 初期値:emptyItems → 実行後:expectedNextItems #expect(newsItemsRecorderResult == [emptyItems, expectedNextItems]) 🌾 self.current.wait(…)は不要かも? https://swiftpackageindex.com/apple/swift-testing/main/documentation/testing/migratingfromxctest ※ XCTestとのMatcher比較:
15. 書き換える際に少し悩んでしまった部分 Quick/NimbleにあるSharedExample & itBehavesLike（it部分の共通化）機能 1. shared_examples： itの部分ないしはcontext〜itの部分を共通化して名前をつけて管理する。 2. it_behaves_like： shared_examplesで共通化したテストコードを呼び出す。該当呼び出したいshared_examplesにつけた名前を付与する。 RSpec.shared_examples 'start_wonderful_event' do it '何かすごいイベントが始まる' do # expect ... で期待する結果を記載する end end describe 'Wonderful Event' do let(:event) { create(:event) } # 個別にitを書くのではなく定義したshared_examplesを呼び出す it_behaves_like 'start_wonderful_event' end ※ 異なるテストケースではあるけれども、比較項目を共通化してまとめている場合がある。その際にはどうするか？と考えてみる。 Ruby on RailsのRSpecに同じ機能がある
16. SharedExample＆itBehavesLikeを手っ取り早く置き換え sharedExamples("イルカが食べるもの") { (sharedExampleContext: @escaping SharedExampleContext) in it("イルカが食べて幸せになること") { // … ※ itの処理を共通化する処理 … } } final class DolphinSpec: QuickSpec { override func spec() { describe("イルカ🐬 さんが食べて幸せになるものを調べるテスト") { // sharedExamplesを利用してitの部分を共通化する // 👉 Closureでテスト対象のものを引き渡した後に期待する答えか否かを確かめる // テスト対象のcontext部分を組み立てる context("鯖🐟 さんを食べる場合") { itBehavesLike("イルカが食べるもの") { Mackerel() } } context("鱈🐟 さんを食べる場合") { itBehavesLike("イルカが食べるもの") { Cod() } } } } } ① shearedExampleの部分はprivateメソッドでまとめる 共通化する部分に関するアプローチ例: ② 場合によっては引数をClosureにしてみる @Suite final class NewsDolphinTest { @Test @MainActor func checkDolphinEatsMackerel() { // … UnitTestを実行 checkDolphinEatsFish(fish: Mackerel()) } @Test @MainActor func checkDolphinEatsCod() { // … UnitTestを実行 checkDolphinEatsFish(fish: Cod()) } private func checkDolphinEatsFish(fish: Edible) { // … ※ itの処理を共通化する処理 … } }
17. まとめ 新しいUnitTestは想像以上に直感的で親しみ易い印象を持ちました これからも積極的に「swift-testing」を利用していきたいと考えています！ 1. Xcode16移行では公式でサポートされる事もあり試験的に導入したがかなり良さそうでした： 従来から描き慣れたXCTestやQuick/Nimbleを利用したUnitTestよりも直感的で親しみ易い感じでした。特にasync/awaitを利用し た処理や非同期処理に関するUnitTestが捗る期待も持っています。 2. Quick/Nimbleで元々記載していたCombine中心の処理でも使っていける余地があると感じました： 本スライドでは簡単な事例の紹介だけでしたが、XCTestとも併せて利用可能である点を活かして既存UnitTestを置き換えていけ ると感じました。全体の形は変化するが「このテストは何を確認したいか？」を整理する事が重要だと思います。 3. 自分もまだMacroを最大限に活用したUnitTestの記載についてはキャッチアップ中： 並列テストやパラメタライズテスト、強力かつ便利なMacroの機能をまだまだ完全に使いこなせている訳ではないですが、シンプ ルで取り組み易い形のUnitTestをこれからも実務で積極的に利用していきたいと考えています。
18. Thank you for listening !