every Tech Blog

株式会社エブリーのTech Blogです。

CursorでXCUITestの仕組みを使ったワークフローの構築でUI実装から修正までを自動化する

はじめに

デリッシュキッチンのiOSアプリを開発している成田です。 デリッシュキッチンではデザイン管理にFigmaを利用し、実装時にはDev Mode MCPサーバーを活用して精度を高めています。しかし、実際にビルドして確認してみると、レイアウト崩れが生じたりで期待するUIになっておらず、手動での「スクショ撮影→Cursorへ添付→指示→確認」という反復作業が発生していました。 この課題を少しでも解決するため、XCUITestによるスクリーンショット自動取得とCursorを組み合わせたUI自己改善ワークフローを構築しました。

概要

今回自動化したのは主に以下の2つです:

  1. スクリーンショットの取得: UI実装後に、自動的にアプリをビルド、画面をナビゲーションしてスクリーンショットを取得
  2. 画像の読み込み: スクリーンショット取得後、画像を読み込んで分析し、レイアウト崩れなどを検出して実装を修正する

実現したワークフロー:

UI実装依頼
  ↓
AIがUIコードを生成
  ↓
xcodebuildでビルド・UITestの実行
  ↓
UITestが画面をナビゲーションしてスクリーンショット取得
  ↓
スクリーンショットパスを一時ファイルに保存
  ↓
画像を読み込んで分析
  ↓
必要に応じてレイアウト崩れなどを自動修正

手順

このワークフローを実現するために必要な設定や実装手順は以下の通りです。

1. XCUITestの実装

XCUITestの標準API(XCUIApplicationscreenshot()メソッド)を使用してスクリーンショットを取得します。

実装すべき内容は以下の通りです:

  1. スクリーンショット取得テスト: 画面をナビゲーションしてスクリーンショットを取得するテストメソッドを実装します。このテストメソッド内で以下の2つのヘルパーを使用します

  2. スクリーンショットヘルパー: XCUIApplicationscreenshot()メソッドを使用してスクリーンショットをファイルに保存するヘルパークラスを実装します

  3. UI要素待機ヘルパー: UI要素が表示されるまで待機するユーティリティを実装します。XCUITestには自動待機機能がありますが、ネットワーク通信や非同期処理による画面更新の遅延がある場合などには、明示的な待機処理が必要です。これにより、テストの安定性を確保できます

これらのファイルをUIテストのターゲットに追加します。

2. スクリーンショット取得スクリプトの作成

スクリーンショット取得は、xcodebuildコマンドを使ってコマンドラインからビルド・テストを実行することで実現します。

スクリプト(scripts/cursor-screenshot.sh)で実装する処理は以下の通りです:

  1. 画面名の受け取りと環境変数の設定: スクリプトは引数として画面名を受け取り、環境変数として設定します。この環境変数はUITestに渡され、どの画面にナビゲーションするかを決定します

  2. アプリのビルド: xcodebuild buildでアプリをビルドします

  3. UIテストの実行: xcodebuild testDynamicScreenshotTests.testTakeScreenshotForScreenを実行します。UITestは環境変数を参照して、画面名に応じて適切な画面にナビゲーションしてからスクリーンショットを取得します

  4. スクリーンショットファイルの検索とパスの保存: テスト実行後、最新のスクリーンショットファイルを検索し、パスを/tmp/cursor_screenshot_info.txtに保存します。このファイルを参照してスクリーンショットを読み込むようにします

3. Cursorのルール設定 - .cursor/rules/my-custom-rule.mdcにUI実装後の自動ワークフローのルールを追加

  - UI実装後のワークフロー
    - UIを新規実装または大幅に変更した後は、必ず以下を実行すること:
      - 大幅な変更の定義: - 大幅な変更の定義: レイアウト、UIコンポーネント、View構造、スタイルなど、レイアウトや見た目に影響を与える変更
      1. 当該の画面に対して`scripts/cursor-screenshot.sh`を実行
      2. 取得した画像をもとに元のデザインと比較してレイアウト崩れなどがあれば修正する
      3. 修正後、再ビルドして確認
      4. 必要に応じて、上記のステップ(1-3)を繰り返す(最大n回まで)

これによって期待するワークフローが実現できました。

おわりに

UIを実装した後は、手動でビルドして確認し、レイアウト崩れなどを発見したら修正依頼を投げるという作業を繰り返す必要がありました。 XCUITestの仕組みを使ったワークフローによってUI実装から自己改善までを自動化することができるようになったので、プロンプトで修正依頼を投げる量を最小限に留めることができるようになりました。 とはいえ、UITestは壊れやすくワークフローの途中でこけることも度々起こりうるので、その辺はデメリットかなと思います。