株式会社レコチョク Advent Calendar 2025

【Android】Maestro + GitHub ActionsによるPR作成時の自動テスト

Last updated at 2025-12-07Posted at 2025-12-07

この記事はレコチョク Advent Calendar 2025 の 8日目です。

レコチョクでAndroidアプリ開発をしている寺島です。
先日、昔よく聴いてたAquaTimezさんとReoNaさんの対バンライブを観てきました。
小さい頃、よく聴いてたアーティストを生でみれるのはすごく感慨深いです。

はじめに

自分が現在担当しているプロジェクトでは2人でAndroidアプリ開発しています。実際に2人で開発をしているとPRレビューを行えない場合が頻発しました。例えば、1人が休んだり、別タスクで忙しかったりするときなどです。

自分たちのチームでは、approveをもらえないと基本的にマージができないようになっています。approveをもらえず開発した内容がマージできないと、開発が思うようにできない場合もあります。開発が完全にできなくなるわけではないのですが、PRがマージされないことで以下のようなことが起こります。

ブランチの管理が煩雑になる
別のPRを出した時にコンフリクト解消が難しくなる

ブランチ管理やコンフリクトの解消は、開発時間を無駄に消費してしまいます。ブランチ管理やコンフリクトの解消をできるだけしなくてすむように、PRをためないような仕組みを検討しました。
検討の結果、PRをためないために、人が確認するほどではないPRについては自動で動作確認を行いマージまでできれば良いと考えました。

「人が確認するほどではないPR」というのは、以下のようなPRです。

表示する文字を変えるだけのPR
AndroidアプリのVersionCodeを変えるだけのPR
未使用のimportや変数を削除しただけのPR

上記のようなPRはアプリの動作に直接影響がでないです。しかし、動作確認をせずにマージをすると、動作しなかった際に手戻りとなります。そこでPRを出した際に簡易な自動テストを回し、最低限の動作確認ができたらマージするというフローを作ることで開発時間の無駄を減らすというのが狙いです。また、簡単なPRに限らず自動テストを行えるようになると、PRがたまることをさらに減らせると考えてます。今回はMaestro + GitHub Actionsを用いて、PRが出されたときに自動テストを行えるか検証しました。

Maestroとは？

最初にMaestroについて説明していきます。MaestroはモバイルアプリやWebアプリのUIテストを簡単に行えるツールです。YAMLファイルでテストを記述することができます。実際のテストコードは以下のようになります。

# flow.yaml

appId: your.app.id
---
- launchApp
- tapOn: "Text on the screen"

Androidの場合は、アプリのパッケージIDを指定して、launchAppというコマンドを指定することで指定したアプリを起動することができます。

今回はMaestroのインストールや簡単な使い方については詳細を省きます。気になる方は参考にリンクをあげておくのでそちらから確認ください。
まず、Maestroの主要な機能について説明していきます。

Maestroコマンド一覧

Maestroではアプリケーションを立ち上げて、実際に操作を行いながら期待の動作になっているか確認することができます。Androidに限らず、iOSアプリやWebアプリケーションでもテストが可能です。

ソフトウェアやアプリケーションのUIが正しく機能するか・正しく表示されるかを確認するテストをUIテスト呼びます。UIテストでは「操作・確認」の2つを実行しながらテストします。Maestroの操作系のコマンド、確認系のコマンドを紹介できればと思います

操作系のコマンド

tapOn

テキストをタップすることができます。画面に表示された文言から一致する箇所をタップします。
下の例だと、"My text" と書かれた箇所をタップします。

- tapOn: "My text"

また、要素のidを指定することでタップさせることも可能です。

- tapOn:
    id: "id" # or any other selector

複数回タップさせたり、タップする間隔を指定することも可能になってます。

- tapOn:
    text: "Button"
    repeat: 3
    delay: 500 # (optional) Delay between taps. Default 100ms

- tapOn:
    id: "someId"
    repeat: 3

参考ページ: tapOn

inputText

テキスト入力欄に対して、テキスト入力を行うコマンドになります。

- inputText: "Hello World"

ドキュメントでは入力する先を指定する方法については詳しく書かれていませんでした。
しかし、 tapOnコマンドで入力したい箇所をタップしてから inputTextをすると期待の箇所に文字を入力できます。

参考ページ: inputText

scroll

画面をスクロールさせます。単純にスクロールをしたい場合はこちらのコマンドを使います。
ただ、こちらはタップしたいコンテンツや領域を通り過ぎてしまう可能性もあります。

- scroll

参考ページ: scroll

back

backコマンドは画面を1つ前の状態にするためのコマンドです。（現状はAndroidのみらしいです。）

- back

参考ページ: back

確認系のコマンド

画面の状態を確認して期待の動作になっているか確認します。中には画面を確認しつつ、操作を行うものもあります。

assertVisible

期待の文字列が表示されているか、要素が表示されているかなどを確認することができます。
また、以下のコードのようにボタンが押下可能な状態か？も確認することができます。

以下の例ではテキストの表示を確認していますが、idで特定の要素が表示されているかも確認できます。

- assertVisible:
    text: "My Button"
    enabled: true

このコマンドは要素が見えているかを確認しますが、見えないことを確認する assertNotVisibleというコマンドもあります。

参考ページ:

extendedWaitUntil

次のコマンドの実行を待つためのコマンドも存在しています。例えば、idで指定した要素が表示されるまで待つということができます。以下のコマンドは指定した文字列が表示されるのを10秒間待ちます。

- extendedWaitUntil:
    visible: "My text that should be visible" # or any other selector
    timeout: 10000      # Timeout in milliseconds

逆に表示されなくなるまで10秒待つということもできます。

- extendedWaitUntil:
    notVisible: 
        id: "elementId" # or any other selector
    timeout: 10000

このコマンドと tapOnを組み合わせて、画面を操作することが可能になります。

参考ページ: extendedWaitUntil

scrollUntilVisible

このコマンドは scrollコマンドに近いですが、さらに便利なコマンドです。
期待の要素が表示されるまでスクロールすることができます。
また、垂直なスクロールだけでなく、水平スクロールもできるため scrollコマンドよりも使用場面は多そうです。

element で指定した要素を中央に持ってくるまでスクロールするということもできます。
その場合は centerElement を true にします。

- scrollUntilVisible:
    element:
      id: "viewId" # or any other selector
    direction: DOWN # DOWN|UP|LEFT|RIGHT (optional, default: DOWN)
    timeout: 50000 # (optional, default: 20000) ms
    speed: 40 # 0-100 (optional, default: 40) Scroll speed. Higher values scroll faster.
    visibilityPercentage: 100 # 0-100 (optional, default: 100) Percentage of element visible in viewport
    centerElement: false # true|false (optional, default: false)

参考ページ: scrollUntilVisible

その他便利なコマンド

Maestroで使える便利なコマンドです。テストの実行をしやすくしたり、テストの結果を記録できます。

takeScreenshot

このコマンドを使うことで、テスト実行中の状態を画像で残すことができます。撮影した画像はMaestroテストを実行したディレクトリへ保存されるようになっています。また、ファイル名も指定することができるので、どこで撮影した画像なのかもわかるようになってます。

- takeScreenshot:
    path: LoginScreen # screenshot will be stored as LoginScreen.png

参考ページ: takeScreenshot

startRecording & stopRecording

画面の録画についても行うことができます。startRecording〜stopRecordingするまでの間を動画として保存できます。撮影した動画はmp4ファイルで保存されます。一時的な画面の状態ではなく、一連の流れを確認できるようになります。

appId: yourAppId
---
- launchApp
- startRecording: recording
...
- stopRecording
...

参考ページ:

runFlow

Maestroでは別ファイルで作られたテストフローを異なるファイルのテストフロー上で参照することができます。
例えば、A.yamlファイル上で、B.yamlというテストフローを呼び出すことができます。
別のテストフローが呼び出せることによって、同一の操作を行うテストで再利用できます。

- runFlow: anotherFlow.yaml

例えば、コンテンツのダウンロードの前にログインが必要な場合に、ログインのテストを別ファイルで作っておけば、別のテストでもログインの操作を再利用できます。

参考ページ: runFlow

テストシナリオを実装する

以下の図のテストシナリオでテストを実装します。

実装したYAMLファイルは以下のようなコードになります。

appId: jp.playpass.android.player_dev
---
- startRecording: login_recochoku # 動画撮影開始

# アプリ起動
- launchApp

# ログイン画面へ遷移するボタンをタップ
- tapOn: "Nav to Login"

# ログイン画面へ遷移したか確認
# 画面に"Login Screen"という文字があれば遷移成功と判断
- assertVisible: "Login Screen"

# ログインを行う
- tapOn: "mail-address"
- inputText: "sample@gmail.com"
- tapOn: "password"
- inputText: "sample"
- tapOn: "Login"

# ログインが完了したか確認
# ログイン完了後に"Download Screen"という文字があれば遷移成功と判断
# サンプル上ではテキストで判断しているが、本来IDで特定の要素が存在するか確認する
- assertVisible: "Download Screen"

# コンテンツAがリスト上に存在するか確認しながらスクロール
# コンテンツAが存在しない場合はテストが失敗する
- scrollUntilVisible:
    element: "contents-A"
    direction: DOWN

# コンテンツAの要素が存在するかIDで確認する
- assertVisible: 
    id: "contents-A"

# コンテンツAのダウンロードボタンを押下する
- tapOn: 
    id: "contents-A"

# ダウンロード済みを示す要素表示まで待ち
- extendedWaitUntil:
    visible: "completed"

# プレイリスト作成画面へ遷移するボタンがあるか確認
- assertVisible:
    id: "Nav to CreatePlaylist Button"

# プレイリスト作成画面へ遷移
- tapOn:
    id: "Nav to CreatePlaylist Button"

# コンテンツAがリスト上に存在するか確認しながらスクロール
- scrollUntilVisible:
    element: "contents-A"
    direction: DOWN

# コンテンツAをタップ
- tapOn: 
    id: "Select-Contents-A"

# コンテンツAが選択状態かを確認
- assertVisible:
    id: "Selected-Contents-A"

# プレイリスト名を入力・保存
- tapOn: "Playlist Name"
- inputText: "Playlist A"
- tapOn: 
    id: "Save-Playlist"

# 作成したプレイリストが表示されるまで待つ
- extendedWaitUntil:
    visible: "Playlist A"

# 最後にプレイリストに楽曲が含まれているか確認する
- assertVisible:
    id: "contents-A"

- stopRecording # 動画撮影終了

ここまででMaestroについての説明は終わりになります。次はGitHub Actions上でMaestroのテストを行う場合の説明をしていきます。

GitHub Actionsでのワークフロー

今回はMaestroを使って、PRをオープンした際にテストするのが1つの目的になっているため、GitHub Actionsでどのように実行してるかについても説明します。

PRをオープンしてからテストが行われるまでの流れは以下になります。

PRをオープンする
PRがオープンされたことを検知し、ワークフロー実行開始
アプリをビルドする
エミュレータを立ち上げる
Maestroをインストールする
テストを実行する

上記のような流れでGitHub Actionsにてワークフローを動作させます。今回はPRのオープンをトリガーにワークフローを実行しました。アプリのビルドやMaestroのインストールはローカルで行ったことを、GitHub Actions上で実行させています。ワークフローを実行する際のトリガーは様々なものを指定することができます。トリガーの指定については、今回は説明しません。

GitHub Actionsのワークフロー上でUIテストを自動実行するにはAndroidエミュレータを起動する必要があります。ワークフローの中でもAndroidエミュレータの起動がポイントになるため、詳細を説明します。

また、Maestroのテスト実行前に以下を行ってますが、今回は説明していません。

アプリのビルド
アプリのインストール

GitHub Actionsのフロー中でエミュレータを起動する

ワークフロー上でエミュレータを起動するために行ったのは以下になります。

エミュレータの起動数＆各端末の設定（今回は1台のみ）
- OSや端末の種類を設定し、複数テストを実行することも可能
AVDのキャッシュ処理
- エミュレータの起動時間を短くするため、キャッシュを行う
エミュレータ起動
- reactivecircus/android-emulator-runner@v2 によるエミュレータ実行

ジョブのマトリクス実行について

ジョブのマトリックス実行についてはこちらから詳細を参照ください。簡単に説明すると、設定を変えた状態で複数のパターンを実行できます。

例えば、以下のように記述したとします。

jobs:
    run-on-comment:
        strategy: 
            matrix: 
                api-level: [29, 33, 36]
                target: [google_apis, google_apis_playstore]

この場合、6パターンのジョブが実行されます。 api-level と target の種類で乗算したパターンだけジョブを実行します。例で示した api-level と target はエミュレータの起動時の設定として使われる値です。

設定を変えて同じジョブを実行するときに便利な方法です。

AVDのキャッシュ処理追加

AVDのキャッシュ処理を行うことで、エミュレータ起動にかかる時間を短縮します。キャッシュ処理の追加をする際にジョブの実行戦略で設定した matrix の値を参照しています。

- name: AVD Cache
    uses: actions/cache@v4
    id: avd-cache
    with:
        path: |
            ~/.android/avd
            ~/.android/adb*
            /usr/local/lib/android/sdk/system-images
        key: avd-${{ runner.os }}-api-${{ matrix.api-level }}-x86_64-google_apis

エミュレータの実行

Androidのエミュレータ端末をGitHub上で実行するには、以下のusesを使います。

reactivecircus/android-emulator-runner@v2
- GitHub

上記リンクのusesを使いエミュレータを起動し、起動した端末でMaestroのテストを実行します。

    - name: run tests
        id: run_maestro_test
        uses: reactivecircus/android-emulator-runner@v2
        timeout-minutes: 40 # タイムアウト時間を40分に設定
        # buildステップの出力を、このステップで使える環境変数に設定する
        env:
            # build_develop_debug_apkで出力したAPKのパスを指定
            APK_PATH_FROM_BUILD: ${{ steps.build_develop_debug_apk.outputs.apk }}
            # parse_commentステップで抽出したymlファイル名を指定
            MAESTRO_TEST_FILE: ./.github/maestro/${{ steps.parse_comment.outputs.filename }}
        with:
            api-level: ${{ matrix.api-level }}
            force-avd-creation: false
            emulator-options: -no-snapshot-save -no-window -gpu swiftshader_indirect -noaudio -no-boot-anim -camera-back none
            disable-animations: true
            script: |
                #!/bin/bash
            
                # 1. Maestro CLIのインストール
                echo "Installing Maestro..."
                curl -fsSL "https://get.maestro.mobile.dev" | bash

                # 2. ビルドしたAPKをエミュレータにインストール
                echo "Installing APK..."
                # 環境変数で指定されたAPKのパスを使用してインストール
                $ANDROID_HOME/platform-tools/adb install "$APK_PATH_FROM_BUILD"
                # APKインストール後、エミュレータが落ち着くまで少し待つ
                echo "Waiting for installation to complete..."
                sleep 20

                # 3. Maestroテストの実行
                echo "Running Maestro tests..."
                # 匿名による利用状況収集を無効化
                export MAESTRO_CLI_NO_ANALYTICS=1
                # パスを通すか、フルパスで実行するのが確実
                ~/.maestro/bin/maestro test "$MAESTRO_TEST_FILE" || true
            
                # 4. エミュレータをシャットダウンするコマンドを追加
                echo "Shutting down the emulator..."
                adb emu kill

上記のYAMLコードについて簡単に説明します。このYAMLコードはGitHub Actionsで実行するワークフローの内容を表しています。
詳細についてみていきます。

env: 他のステップで出力した結果をこのステップで参照
with: エミュレータの詳細を設定
- api-level: AndroidのOSバージョン
- force-avd-creation: キャッシュがある場合は新規作成をスキップするか？（falseでキャッシュがある場合はスキップする）
- emulator-options: エミュレータのオプション（画面なし・GPU高速化）を設定
- disable-animations: これでアニメーションの有り無しを指定
  - アニメーションをOFFにすることでUIテストが失敗しづらい
script: Maestroのテストを実行する（コマンドで指示できる）
- Maestroのインストール
- ビルドしたアプリのインストール
  - gradleでビルドしたアプリをadbでインストール
- Maestroのコマンドでテスト実行
- エミュレータのシャットダウン

上記の流れでGitHub Actions上でAndroidアプリのUIテストを実行できます。

Maestroのテストコードの自動作成を検証する

最初はアプリの動作に影響のないPRで、最低限の動作確認ができれば良いと考えていました。しかし、Maestroを触っているうちに生成AIを組み合わせれば、PRの変更差分に合ったテストを自動で作成・実行までできるのではないかと思いました。

以下のような流れでPRごとに自動テストを作成・実行することになりそうです。

PRの変更差分を抜き出す
生成AIに変更差分を伝える
テストケースを考えてもらう
Maestro MCPを使って画面を操作しつつ、テストケースのYAMLファイルを作る
作ったYAMLファイルを実行する

PRの変更差分からテストケースを作成する

まずPRに合ったテストを作るためにはPRでどのような差分が発生しているかを把握する必要があります。今回はCursor使ってその差分を生成AIに伝えてテストケースを作成します。

CursorとGitHubは連携することで、PRの差分を取ることが可能です。連携するには以下のようにスクリーンショットの赤枠から連携を行います。この画面はCursorの右上にある⚙️から遷移できます。

GitHubとの連携ができたらCursorにテストを作りたいPRのURLを渡して、差分を取得します。画像のようにURLはブロック状になります。

上記の依頼を投げると以下のような結果が返ってきます。

※実行をするか何度も聞かれていますが、全て行うように指示しています。

# PR #1532 の差分サマリー

## 変更ファイル
- ImageListFragment.kt

## 変更内容
1. インポート文の順序変更（ktlintの自動整形）
2. ImageListItem コンポーネントのレイアウト修正:
  - タイトルのテキストアライメント: TextAlign.Center → TextAlign.Start（左詰め）
  - メニューアイコン（MoreVert）を右端に固定
  - タイトルを左端からメニューアイコンまでの幅に設定
  - 不要な padding(16.dp, 0.dp) を削除
  - 制約の調整:
    - メニューアイコンの start.linkTo(title.end) を削除（右端固定のため）
    - タイトルの height = Dimension.wrapContent を width = Dimension.fillToConstraints に変更

## コミット履歴
- aaaaaaaaa - テキストを左詰にする
- bbbbbbbbb - 上に表示される画像と同じ分だけ幅を確保する
- ccccccccc - 画像リストのアイテムのタイトルとメニューを制約幅いっぱいに広げる

このPRは、画像リストアイテムのタイトル表示を中央揃えから左揃えに変更し、メニューアイコンを右端に固定するUI改善です。
詳細な差分の確認やレビューが必要であれば知らせてください。

これでPRでの変更差分は取得できていそうです。この差分からCursorにテストケースを作ってもらうように依頼しました。依頼を投げたところ、テストケースを作成してくれました。

実際に作られたファイル

以下は実際にCursorが出力したMarkdownのファイルです。

# 画像リストレイアウト変更テスト（PR #1532）

## 概要

このテストは、PR #1532で行われた画像リストアイテムのレイアウト変更を検証するためのMaestro UIテストです。

## PRの変更内容

### 変更ファイル
- `app/src/main/java/jp/playpass/android/player/ui/fragment/ImageListFragment.kt`

### 変更詳細

1. **タイトルのテキストアライメント変更**
   - 変更前: `TextAlign.Center`（中央揃え）
   - 変更後: `TextAlign.Start`（左詰め）

2. **メニューアイコンの配置変更**
   - 変更前: タイトルの右側に配置（`start.linkTo(title.end)`）
   - 変更後: 右端に固定（`end.linkTo(parent.end)`）

3. **タイトルの幅設定変更**
   - 変更前: `height = Dimension.wrapContent`
   - 変更後: `width = Dimension.fillToConstraints`

4. **パディング削除**
   - 変更前: `.padding(16.dp, 0.dp)`
   - 変更後: パディングなし

## テストケース一覧

### テストケース1: 基本レイアウト確認
- **目的**: 画像リストが正常に表示されることを確認
- **確認項目**:
  - 画像リスト画面に遷移できること
  - 画像アイテムが表示されること

### テストケース2: タイトルの左詰め表示確認
- **目的**: タイトルが左詰めで表示されることを確認
- **確認項目**:
  - タイトルテキストが左端から始まっていること（スクリーンショットで確認）
- **注意**: テキストアライメントは直接アサートできないため、スクリーンショットで視覚的に確認

### テストケース3: メニューアイコンの右端配置確認
- **目的**: メニューアイコンが右端に配置され、正しく動作することを確認
- **確認項目**:
  - メニューアイコンが右端に配置されていること（スクリーンショットで確認）
  - メニューアイコンをタップするとコンテキストメニューが表示されること

### テストケース4: 長いタイトルの省略表示確認
- **目的**: タイトルが長い場合に3点リーダーで省略されることを確認
- **確認項目**:
  - タイトルが1行で表示されること（`maxLines = 1`）
  - 長いタイトルが3点リーダー（...）で省略されること
- **注意**: 実際のデータに長いタイトルがある場合のみ有効

### テストケース5: 複数アイテムでのレイアウト一貫性確認
- **目的**: 複数の画像アイテムでレイアウトが一貫していることを確認
- **確認項目**:
  - すべてのアイテムでタイトルが左詰めで表示されること
  - すべてのアイテムでメニューアイコンが右端に配置されること

### テストケース6: 画像アイテムのタップ動作確認
- **目的**: レイアウト変更がタップ動作に影響しないことを確認
- **確認項目**:
  - 画像アイテムをタップすると画像ビューアーが表示されること
  - 画像ビューアーから戻れること

### テストケース7: メニューアイコンの動作確認
- **目的**: メニューアイコンが正しく動作することを確認
- **確認項目**:
  - メニューアイコンをタップするとコンテキストメニューが表示されること
  - メニューを閉じられること

## 関連情報

- PR: https://github.com/sale-recochoku/sale-player-android/pull/1532
- 変更ファイル: `app/src/main/java/jp/playpass/android/player/ui/fragment/ImageListFragment.kt`

テストケースは作ってくれたものの、このMarkdownファイルを元に実際にテストが作成できるかは確認できていないです。ただ、PR差分を生成AIに渡し、テストケースを考慮してもらうという流れは容易にできることがわかりました。

テストケースを作成するときの注意点や出力内容の指示を細かく行えば、Maestroのテストケースを作成することも可能だと考えてます。

Maestro MCPについて

Maestroは、MCPが用意されています。Maestro MCPを使って、生成AIに指示することで、Maestroの機能を部分的に使えます。

今回はMCPを使うとどのようなことができるかを紹介していきます。Maestro MCPのツールは、シチュエーションに応じたものが存在しています。今回は、自動でテストを作成する上で使えそうなツールを紹介します。

list_devices

ツールの実行時にコマンドからアクセスできる実機端末を一覧で取得します。一覧を取得する際も「list_devices」と書いたり、「Maestroを使って、接続中の端末を表示してください」と指示したりすると一覧を表示してくれます。

実際に実行した時の返答が以下です。端末のデバイスIDを表示してくれています。

端末リストを取得しました。以下が現在の状態です。
## 接続中の端末
### Android実機
- Device ID: ***************
- Name: Pixel 4a (5G)
- Platform: android
- Type: real device
- Status: 接続中

## 利用可能な端末（未接続）
### Androidエミュレータ
- Pixel_9_Pro_Fold (emulator)
- Pixel_9a (emulator)
- Small_Phone (emulator)
- Wear_OS_Large_Round (emulator)

### iOSシミュレータ
多数のiOSシミュレータが利用可能（iPhone 16/15/14/SE、iPad Pro/Air/miniなど、各種iOSバージョン）

### Webブラウザ
- chromium (browser)

現在、接続中で使用可能な端末は Android実機 Pixel 4a (5G) のみです。この端末でMaestroのテストを実行できます。

Android Studioで起動したことのある端末まで表示してくれています。 list_devices コマンドを使って使用できる端末を探し、探した端末でアプリを起動させます。

launch_app

アプリの起動をすることができるツールです。Cursorには先ほど使用できる端末を聞いているので、「使用できる端末で〜〜〜アプリを開いて」と指示をすると、実際に期待のアプリを開いてくれます。

application Idを指定すると、起動するアプリを間違えることもなさそうです。

inspect_view_hierarchy

画面の状態をCSVファイルで取得することが可能です。このツールを使えば、現状の端末の画面の状態を取得することができます。Maestro MCPでは画面タップの操作もできるため、画面を遷移させながらMaestroのテストケースを自動で作成するのに使えそうだと思ってます。

PRの変更差分からテストコードを自動で作成できそうか？

今回の検証で可能だと分かったことは以下です。

GitHub上のPRから差分を取得してテストケースを作成
CursorからMaestro MCPを使って端末・アプリの操作
Cursorがアプリ画面の構造を把握できるようにする

MaestroのテストケースをYAMLファイルとして、Cursorに作成してもらうことも可能ではないかと思います。画面を遷移しながらその画面での操作をYAMLファイルに記述していくようなイメージで、実際にMaestroのテストケースを作れると考えてます。

まとめ

今回はGitHub ActionsとMaestroでPR作成時にテストを実行する方法を試してみました。また、PRの差分からMaestroのテストコードが作成できないかを一部検証してみました。
結果としてはPRごとにMaestroのUIテストを自動で作成し、実行することが可能なのではないかということがわかってきました。
生成AIを使ってできる限り自動で行える部分を増やしていき、自分たちの作業時間をより有効に使えるようにしていければと思ってます。

ここまで読んでいただきありがとうございます。

参考

明日のレコチョク Advent Calendar 2025 は9日目＜知っておくと便利！VSCodeの地味に役立つ設定4選＞です。

この記事はレコチョクのエンジニアブログの記事を転記したものとなります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up