SwiftTestingによる_モダンなiOSテスト手法とBDD.pdf

20251021【4社共催！】After iOSDC & DroidKaigi 2025にて登壇した資料

Transcript

1. Copyright coconala Inc. All Rights Reserved. SwiftTestingによる モダンなiOSテスト手法と BDD 小林　慎吾　Shingo (ごん : GON)
2. Copyright coconala Inc. All Rights Reserved. ※ここに注釈テキストが入れられます。 マーケットプレイス事業部 iOSエンジニア 小林　慎吾 自己紹介 2 業務 - iOSチームエンジニア - ココナラに転職して 6ヶ月 - 好きなココナラ　サービス「ロゴ作成」 - 行ってみたい旅行先！！　ハワイ！ 🏝 プライベート - 1児の父 - SIer → フィットネスベンチャー →フリーランス等経て現職 - 子供と電車博物館に旅行　 🚃
3. Copyright coconala Inc. All Rights Reserved. 3
4. Copyright coconala Inc. All Rights Reserved. 4 99.75 % クラッシュフリーレート基準値
5. Copyright coconala Inc. All Rights Reserved. ・ココナラは多数のサービスが一体化した 巨大アプリ ・機能もドメインも異なり、全体仕様の把握 が困難 ・仕様が人に依存していたのが課題 ココナラ- プロが集まる日本最大のスキルマーケット 5
6. Copyright coconala Inc. All Rights Reserved. ① 大規模アプリで仕様が見えづらい 　→ 当初テストカバレッジが少なく、動作確認は E2Eや人に依存 ② PresenterからViewModelへ再設計 　→ テストしやすく、状態管理をシンプルにしている ③ ViewModelテストを書き始めるも 　→ XCTestでは読みにくく、仕様として残せない ④ SwiftTestingで “仕様として読めるテスト ” を目指す 　→ @Testで仕様を日本語化、 BDDスタイルで明文化 大規模アプリならではの悩み 6
7. Copyright coconala Inc. All Rights Reserved. 関数名から意図が読みづ らい 並列実行の仕組みが標準 ではなく、時間がかかる。 ネストが深く可読性が悪い XCTestでは読めなかった仕様 7 テストから仕様を読むのは難しかった
8. Copyright coconala Inc. All Rights Reserved. SwiftTestingで“読める”テストに 8 コードで仕様を語り、日本語で伝わるテストへ 読める：@Suite @Test #expectで仕様がそのまま伝 わる 整理できる： @SuiteでInput 配下を階層化 BDDに最適 ：Given/When/Thenと自然に 合体
9. Copyright coconala Inc. All Rights Reserved. 特徴 ・動作駆動開発　ユーザー視点での動作を重視した記述 ・「Given（前提）– When（操作）– Then（結果）」で記述しております。 ・テストがそのまま仕様書になる BDDとは？ ― 仕様をチームで “共有できる ”開発手法 9
10. Copyright coconala Inc. All Rights Reserved. → 例: onAppear() // 画面を表示した時 onTapNext() // 「次へ」をタップした時 実際のアプリ使用シナリオに基づいたテストが可能に ViewModel設計と行動の一致 10 ViewModelのInput＝行動
11. Copyright coconala Inc. All Rights Reserved. SwiftTesting × BDD 11 BDDで仕様書のように読む
12. Copyright coconala Inc. All Rights Reserved. 🧩 行動設計 　└ onTapNext() ←→ 「次へ」をタップした時 🧩 BDD 　└ Given / When / Then → 仕様書のように “読む” 🧩 SwiftTesting 　└ @Suite / @Test → 振る舞いを自然言語で表現 テストが仕様を語る世界へ 12 SwiftTesting × BDD × 行動設計
13. Copyright coconala Inc. All Rights Reserved. ・「書かされているテスト」から「設計を語るテスト」へ変わった 　最初は義務感で書き始めたが、書くほど仕様を整理する時間になった。 ・自然言語で書けるからレビューがしやすい 　テスト名を読むだけで「どんな動きを担保しているか」がチームで共有できた。 ・高カバレッジ＝安心感ではなく、理解の透明化 　数字よりも、仕様とコードの対応関係が明確になったことが一番の成果。 “テストを書く＝仕様を残す ”という意識が定着した 　私含む新規参加者がテストから仕様を理解できるようになった。 実装してみて感じたこと 13 SwiftTesting × BDD × 行動設計
14. Copyright coconala Inc. All Rights Reserved. ② テストしやすいような実 装設計 ① SwiftTesting × BDD によ る“読める”テスト ③テストカバレッジを上げ る まとめ - 品質を支える 3つの取り組み 14 今日の交流会では、現場あるあるや苦難　工夫を語りたいです！ 仕様が複雑な中で、 ViewModel のInputを「行動」として設計。 onAppear や onTapNext など、 ユーザー行動単位でテストを整 理できた。 Given / When / Then の流れ で、テストが仕様書のように読め る。 @Suite / @Test によって自然言 語的に書けるようになった。 数字よりも、テストを書くことで設 計が明確になる実感。 テストが「守り」ではなく、理解と 品質を高める手段になった。 99.75 %を支える取り組み
15. Copyright coconala Inc. All Rights Reserved. おしまい　 ご清聴ありがとうございました！ 15