cluster iOS開発におけるテストのルール整備

こんにちは。8月からクラスター株式会社でiOS Engineerとして働いているshindyuです。
この記事ではclusterのiOS開発におけるテストのルール整備をした話を紹介します。

# はじめに

clusterのiOSネイティブアプリ部分は2020年から開発されています。
コードはすべてSwiftで書かれており、SwiftUI、Swift Concurrency、Combineなどの導入にも積極的に取り組んでいます。

これまでは少数のエンジニアによってコード品質が保たれてきましたが、今後の組織拡大に伴い新規メンバーが増えるとコードの全容や既存仕様を把握しきれないことも予想できます。その際テストコードが適切に書かれていると安心ですし、仕様理解の助けにもなります。
今後もサービス開発を加速させ続けるために、誰でも必要なテストをスムーズに追加できるよう自動テストのルールをdesign doc化して整理することにしました。

# design docの文化

design docとはクラスター社内で扱う開発ドキュメントで、他のメンバーからレビューをもらったり、そこで生まれた議論の過程が残っていることが特徴です。(参考:clusterの設計ってどうやってるの?
クラスター社ではこまめにドキュメントを残す文化が根付いているので、後から入った人でも仕様などをキャッチアップしやすくなっています。自分はかなり好きな文化です。

今回はチームの開発ルールに関する内容だったため、一旦自分が叩きとなるルールをdesign docとして作成し、関係者のレビューを受けながら内容を充実させていくことにしました。
メンバーの合意を取って進められる安心感もありますし、自分では気づかなかった指摘をもらえたり、冗長かと思って省略していた箇所をレビューによって明文化することもできました。

design doc上でのレビューの様子

# 整備したルールの紹介

こうして決まったルールの中から一部を紹介します

カバレッジ向上を目標にしない

コードカバレッジは定量的で分かりやすい指標です。しかしカバレッジ向上を目標に設定してしまうと、本来必須ではないテストコードが闇雲に生み出される可能性もあります。これはクラスター社のバリューである”加速”にそぐわないと判断したため「カバレッジ〇〇%以上」といった目標は持たないことにしました。

どのファイルを対象にテストするか

一方で、ModelやUseCaseなどのサービスの核となるロジックを持つ箇所や、課金周りなどのクリティカルな箇所については手を加える際はテスト追加を必須としました。

テストで扱うライブラリ

テストで扱うのは標準のXCTestと、protocolからモックを生成するためのmockolo、テストデータを簡易生成するためのStubKit のみとしました。
新規開発者がキャッチアップしやすく、また新しいOSでテストが動かなくなるようなリスクを回避するため、できるだけライブラリに依存しない方針としました。

具体的なテストコードの書き方

テスト名には条件と期待値を記載することにしました。テストコード内ではArrange(準備)、Act (実行)、Assert(検証)ごとにコメントで区切って可読性を高め、新規開発者がテスト内容を把握するコストが下がるようにしました。
Arrange-Act-Assert

# 運用するための工夫

決まったルールを個々人の意識だけで運用するのは大変です。無理なく運用していくためにいくつか工夫したポイントを紹介します。

GithubActionsの改善

PullRequestにルールで決めたテスト対象とするファイル(UseCase, Modelなど)が含まれる場合、対応するテストファイルが更新されていなければPullRequestにコメントを追加するGithubActionsを設定しました。差分ファイルの取得には get-diff-action を利用しています。

またUnitTestを実行しているJobに xcresulttoolを追加して、テスト結果とカバレッジをJobSummary上で確認できるようにしました。しばらくは毎週行っているiOSチームの定例で実行時間やテストケースの推移をみていくことにしています。

Xcode File Templatesの追加

上述したテスト名のルールやArrange、Act、Assertなどの具体的な例をFileTemplatesに追加して、テストコードのスタイルに統一性を持たせるようにしました。

テスト用のTemplatesを用意

具体的なテストコード例を記載

# おわりに

以上、直近行ったテストのルール整備への取り組みについてご紹介しました。

どういったスタイルでテストに取り組むかはチームの状況よって変わってきますが、チームでドキュメントをレビューしながらルールを決めていくやり方はおすすめです。
またGithub Actionsによる自動化やFileTemplatesを上手く活用することで、人が頑張る運用を減らしてチームの生産性を上げることもできます。
この記事を読んでいただいた方の今後の開発の参考になれば幸いです。

クラスターではモバイルエンジニアをはじめとした各種ポジションを募集中です!
少しでも興味をもっていただけた方は是非以下のリンクから採用事例・採用情報をご覧ください!