ブランチ機能を用いると、プロジェクト全体で管理するテストケースやその実行に影響を与えずに、独自のワークスペースで変更を追加・検証することができます。この機能を用いることで、チームが安全かつ迅速なコラボレーションを行うことができます。
ブランチ機能について解説したブログも公開しておりますので、ぜひご覧ください。
本機能をお使いいただけるのは下記プランご契約のお客様になります：
- エンタープライズプラン
- 新スタンダードプラン（2025）
目次
1. ブランチを用いるユースケース
- 失敗したテストケースを個人のブランチで修正・検証し、他の人の作業に影響を与えない
- リリース予定の新機能を
developブランチでテストし、リリースと同時にmainにマージする
2. ブランチの推奨構成
MagicPodが考えるベストプラクティスは以下のブランチ構成となります。
リリースブランチ: 本番環境用
↑
デフォルトブランチ: 開発環境用・CIで毎日実行
↓
フィーチャーブランチ: 個人作業用デフォルトブランチ(mainブランチ)
デフォルトブランチの役割は以下となります：
- 開発環境向けのテストケースを管理
- CIツールで毎日自動実行
- 基準となるブランチ
MagicPodのプロジェクトはすべてブランチで管理されています。明示的にブランチを作っていなくとも、プロジェクトのリソースは暗黙にmainブランチ内に存在しており、これをデフォルトブランチと呼びます。初期状態ではブランチ名はmainとなっていますが、ブランチ名の横にある三点マーカーよりブランチ名の変更が可能です。
デフォルトブランチはアプリの開発環境向けに使用することを推奨しています。
リリースブランチ
リリースブランチの役割は以下となります：
- 本番環境向けのテストケースを管理
- バージョンごとに作成（例：release-v2.1）
- 本番モニタリングに使用
テスト対象アプリの新しいバージョンがリリースされる度に、新しいリリースブランチをデフォルトブランチを元に作成し、本番環境でテストすることをお勧めします。
フィーチャーブランチ
フィーチャーブランチの役割は以下となります：
- 個人の作業用
- 修正や新規作成の検証用
デフォルトブランチの一部を変更する場合に、フィーチャーブランチを作成することをお勧めします。
フィーチャーブランチにて修正・検証を行い、問題なければデフォルトブランチにマージさせるといった使い方ができます。マージ後には、当該ブランチは削除されます。
3. ブランチを使う
ブランチはプロジェクトの下に作られる独立したワークスペースです。他のブランチに影響を与えずに、個人の変更を追加・検証することができます。
MagicPodのプロジェクトはすべてブランチで管理されています。明示的にブランチを作っていなくとも、プロジェクトのリソースは暗黙にmainブランチ内に存在しており、これをデフォルトブランチと呼びます。
ブランチ内で検証した全ての変更は、準備が整った段階でデフォルトブランチにマージすることができます。
3-1. ブランチを作る
プロジェクト配下のページでは、右上の現在のブランチ名が書かれた箇所の右にある、メニューボタンからブランチを作成できます。
ブランチを作成すると、メニューの表示が変化し、作成したブランチに切り替わります。
ブランチの一覧を見ると、今作成したブランチ以外にデフォルトブランチが表示されています。これが、プロジェクト全体の主要なワークススペースであり、状況に応じてどちらのワークスペースで編集を行うか切り替えることができます。
これにより、テストケースや共有ステップなどを、デフォルトブランチに影響を与えずに編集・実行する準備が整いました。
なお、新規のブランチはデフォルトブランチからのみ作ることができます。つまり、デフォルト以外のブランチAからブランチBを作ることはできません。
3-2. テストケースを編集する
ブランチ内では、通常と同じようにテストケースと共有ステップを編集することができます。誤ったブランチで編集を行わないよう、右上のメニューの表示で、目的のブランチで編集していることを確認してください。
ブランチ内で編集したテストケースや共有ステップの一覧はブランチの詳細ページから確認することができます。右上のメニューで「ブランチ詳細・マージ」をクリックしてください。
「変更を確認」メニューから個別の変更履歴を確認できます。
以下の機能はブランチ内での利用が制限されます。
- テストケース・共有ステップの新規作成
- 共有UIの追加・削除
- UI一覧画面における「セクション追加」「UI整理」機能
- テストケース名や説明などの編集
- UIの使用数確認
- 削除されたUIを含むテストケースの一覧での確認
右上にメニューが存在しないページでは、表示されている内容が全てのブランチで共有されていることを意味します。例えば、以下のリソースを更新した場合は、他ブランチでも同様の更新が適用されます。
- 一括実行設定
- テストケースラベル
- 多言語データパターン
- 画像差分
3-3. テストケースを実行する
ブランチ内ではテストケースの単体・一括実行をいずれもサポートしています。
単体実行の方法は変わりません。テストケース編集画面の左下から実行してください。ブランチを切り替えて実行したい場合は右上のメニューからブランチを切り替えてください。
一括実行では、実行前にブランチを選ぶことができます。「テストを一括実行」ボタンをクリックした後、実際に実行が開始される前にブランチを選ぶ画面が表示されます。
コマンドラインによる一括実行でもブランチを指定することができます。詳細はMagicPod Web APIのページでPOST /v1.0/{organization_name}/{project_name}/batch-run/のリクエスト形式をご確認ください。また、一括実行の「コマンドラインで実行」メニューからもリクエストの形式を確認することができます。
3-4. マージする
ブランチ内での編集・動作確認が終わったら、変更内容をデフォルトブランチにマージしましょう。右上のメニューからブランチ詳細ページに移動し、変更一覧を確認してください。
不要な変更や意図しない変更を確認した場合は各変更行の右メニューから「変更を破棄」をクリックしてください。ブランチで編集を加える前の状態に戻すことができます。間違えて変更の破棄をしてしまった場合でも、履歴ページで任意のバージョンに戻すことができます。
一覧の変更を全て確認し終えたら、マージボタンをクリックしてブランチをマージしてください。マージコメントをブランチでの編集内容に沿ったものにすることで、チームの他のメンバーにとっても履歴が理解しやすくなります。
なお、ブランチをマージするとそのブランチは閉じられ、変更を追加したり、そのブランチでのテストを実行することはできなくなります。
⚠️ ブランチ管理の対象、つまりマージの対象は以下のリソースに限られます
- テストケース
- 共有ステップ
- テストケースと共有ステップ内で使用されるUI
- データパターン
例えば、ブランチ内で新規にUIを作成しても、それがテストケース内で使用されていない場合には、そのUIはマージされません。
3-5. コンフリクトを解決する
デフォルトブランチと、そこから作成したブランチの両方で同じテストケースを編集した場合にコンフリクトが発生します。コンフリクトが発生している状態ではブランチをマージすることはできません。それぞれのブランチで加えた異なる変更はシステムで自動解決できないため、手動で解決していただく必要があります。
コンフリクトが発生したリソースは画面上で警告が表示されます。「コンフリクトを解決」と書かれたボタンを押して「コンフリクト解決」画面を利用すれば、解決することができます。
上記のケースではmainとdevelopブランチのそれぞれでテストケースに異なる変更を加えたためにコンフリクトが発生したようです。それぞれの変更内容を確認しましょう。
コンフリクト解決画面では、左側にmainブランチ、右側にdevelopブランチの内容が表示されます。中央にあるのが「解決バージョン」で、コンフリクトを解決した後画面右上の「解決済みにする」ボタンを押すと、その内容がdevelopブランチに反映されます。
オレンジ色の枠で囲われた範囲は、mainブランチとdevelopブランチ両方で異なる修正を加えた結果、自動的にマージできなくなっている範囲です。
一方、オレンジ色の枠で囲われていない範囲は、自動的にマージできた範囲です。下図の場合、developブランチのみがステップを追加した箇所なので、解決バージョンに追加したステップが自動で取り込まれています。
オレンジ色の枠で囲われた範囲では、矢印ボタンを押して必要なステップを左右の列から取り込んだり、解決バージョンにある不要なステップにマウスカーソルを当てると現れる×ボタンを押したりして、望ましい内容になるまで解決バージョンを編集してください。
オレンジ色の枠に囲まれた範囲における解決バージョンの編集が終わったら「この範囲を解決済みとする」ボタンをクリックしてください。
以上を繰り返して、オレンジ色の枠に囲まれた範囲を全て解決済みとしたら、画面右上の「解決済みにする」ボタンをクリックしてコンフリクトを解決済みとしましょう。
ダイアログボックスによる指示に従って履歴に保存すると、解決バージョンに書かれた内容がdevelopブランチに反映されます。
保存できたら、修正後のテストケースを確認しておきましょう。
4. サポートバージョン
ブランチを用いてローカル環境でテストを作成・実行する場合はMagicPodDesktopのバージョンを1.19.0以上にアップデートしてください。最新のMagicPodDesktopはこちらからダウンロードしてください。
テストの実行環境にクラウド・外部クラウドサービスを用いる場合はアップデートは必要ありません。
5. よくある質問
Q.
ブランチを切り替えたところ、「ページが見つかりません」と表示されました。
A.
例えば、mainブランチにテストケースAが存在していてdevelopブランチには存在しないという場合に、テストケースAを編集中にmainからdevelopにブランチを切り替えることで「ページが見つかりません」が表示されることがあります。一般に、片側のブランチでテストケースや共有ステップが削除またはゴミ箱に入っている状態で同様の現象が発生する可能性があります。
テストケースの一覧ページ等でブランチを切り替えていただければこの問題は発生しませんので、ページを移動して再度お試しください。
Q.
ブランチをマージした後に、類似した2つの共有UIが作成されていることがあるのは何故ですか？
A.
特殊なケースで、マージのタイミングで元々の共有UI(例えば画面1)と類似した新たな共有UIが作成される(画面1と画面1(1)の2つになる)ことがあります。これは、例えば以下のようなケースで発生します。
-
mainブランチではテストケースAのみが共有UI画面1を使用していた -
developブランチを作成し、画面1に変更を加えた -
mainブランチではテストケースBが新たに画面1を使用するようになった -
developブランチをマージした
この際に、単純に画面1をdevelopブランチの内容で上書きしてしまうと、テストケースBの実行に意図しない問題を生じる可能性があります。そのため、新たに共有UIを作成し、テストケースAでは画面1を、テストケースBでは画面1(1)を使用することで、意図通りの動作になることを保証しています。
Q.
コンフリクトを解決した際、修正したブランチにおいて類似した2つのUIが作成されていることがあるのは何故ですか？
A.
前の質問と同様に特殊なケースで、コンフリクトを解決したタイミングで元々のUI(例えば画面1)と類似した新たなUIが作成される(画面1と画面1(1)の2つになる)ことがあります。これは、例えば以下のようなケースで発生します。
-
mainブランチではUI画面1のとある要素Aについて、css=div[aria-label=111]というロケーターを設定していた -
developブランチではUI画面1のとある要素Aについて、css=div[aria-label=222]というロケーターを設定していた -
mainブランチにおけるテストケースAとdevelopブランチにおけるテストケースA、それぞれにおいてUI画面1を使用するステップを追加した -
mainブランチにあったUI画面1を使用するステップと、developブランチにあったUI画面1を使用するステップ、両方をテストケースAに含めてコンフリクトを解決した
この際に、単純に画面1をdevelopブランチの内容で上書きしてしまうと、テストケースAの実行に意図しない問題が生じる可能性があります。そのため、新たにUIを作成することで、意図通りの動作になることを保証しています。
Q.
共有ステップ変数をコンフリクト解決画面で操作できないのは何故ですか？
A.
共有ステップ変数は、解決バージョンの処理で実際に使用しているものを自動で取り込むこととしています。これは、解決バージョンの処理で使用しているにもかかわらず、該当の共有ステップ変数を取り込み忘れる、といったミスを防ぐためです。