mablは、信頼性の高いエンドツーエンドのテストをCI/CDパイプラインのすべての段階で簡単かつ迅速に実行します。CI/CD環境での継続的なテストは、ソフトウェア開発者、QAエンジニア、プロダクトマネージャ、その他のビジネス関係者に、問題がプロアクティブに解決されているという安心感を与えます。

DevTestOpsのワークフローの一部としてmablテストを実行するには、テスト環境へのデプロイ後に実行する方法と、開発プロセスの初期段階であるコードビルド後に実行する方法があります。この記事では、プル（マージ）リクエストのテストに関する検討事項を含め、これら2つの方法の概要を説明し、追加のハウツーリソースを参照します。

デプロイメントごとのテスト

デプロイメントプロセスにmablテストを統合すると、CI/CDパイプライン内のホスティング環境にコードがデプロイされると同時に、複数のブラウザでエンドツーエンドのユーザーエクスペリエンスをテストすることができます。すべてのmablテストは環境をまたいで実行できるように設計されているので、プル/マージリクエストをテストするための一時的なプレビュー環境から、永続的なステージング環境、さらには本番環境まで、複数の環境で同じテストを簡単に実行することができます。バグの中には本番環境でしか発現しないものもあるので、本番環境でのテストも恐れずに行うべきです。

mablをCI/CDパイプラインに統合して、デプロイ時にテストを実行するには、使いやすい順に以下のオプションのいずれかを使用します。

1. 既存のCI/CDの統合 - GitHub Actions、Bamboo、Jenkinsなどの統合が可能です。
2. mabl CLI - Node.jsパッケージのインストールと実行が可能なあらゆるCIツールと統合できます。
3. mabl APIs - mabl CLIを使用できない場合や、より詳細な制御が必要なCIツールと統合できます。

この仕組みは、上記のメカニズムのいずれか（例：mabl CLI）を使用して、mablのデプロイメントイベントを作成します。これは、どのテストプランをどこで実行するか（環境やブラウザの指定など）、どのような設定オプションを適用するか（クレデンシャルやHTTPヘッダーの指定など）をmablに伝えるものです。

📘

テスト組織の考慮事項

デプロイ時に実行したいテストを一つ以上のプランにまとめておくことが重要です。プランのラベルを使用して、実行するプランを制御することができます。現在のところ、プランのラベルとテストラベルは別物なので、テストのラベルを使用して、デプロイメントイベント用のテストグループを mabl で実行することはできません。

何百ものテストを並行して実行した際の迅速なフィードバックや、mablクラウドでテストを実行した際にmablが生成する豊富な診断データ（例：DOMスナップショット、ネットワークアクティビティ）やインサイト（例：視覚的変化）の恩恵を受けられるよう、環境にデプロイする際にはmablクラウドでテストを実行することをお勧めします。

プルリクエストのテスト

多くのソフトウェア開発チームは、プルリクエスト（PR）のレビュープロセスの一環として、ユニットテスト、静的解析、その他様々なコードチェックを行っています。これらのチェックは、開発プロセスの初期段階で問題を発見するのに役立ち、また、コード品質の後退の有無をPRレビュー担当者に知らせることで、コードレビュープロセスを迅速に行うことができるため、非常に価値があります。

👍

プルリクエスト vs マージリクエスト

プルリクエストとは、GitHub や BitBucket などのソースコントロール管理 (SCM) ツールで使われる用語で、コードの変更が git ブランチにプッシュされ、レビューの準備が整ったことをチームに通知するプロセスのことです。「pull」という言葉は、git ユーザーがレビューやマージの対象となるブランチのソースコードのローカルコピーを取得するために最初に実行する git コマンド (git pull) に由来します。問題がなければ、git ユーザーは git merge コマンドを実行してコードの変更をメインブランチにマージします。このように、GitLab のような他の SCM ツールではプルリクエストの代わりにマージリクエストという用語を使っていますが、基本的には同じ意味です。mabl のヘルプドキュメントでは、一貫性を保つためにこれらの用語のうちのひとつであるプルリクエストだけを使っています。

これまでチームは、PRチェックの一環としてエンドツーエンドのUIテストを追加することを避けてきました。これは、テストが不安定で脆く、実行に非常に時間がかかるからです。しかし、mablのダイナミックウェイティング、自動ヒーリング、並列実行、ヘッドレスモードなどのおかげで、もはやそのようなことはありません。PR段階でUIやAPIレイヤーのエンドツーエンドテストを実施することで、チームがコード変更を承認する際の信頼性が高まり、継続的なデリバリープロセスを加速することができます。

GitHub ChecksやBitBucket Code Insightsとの統合を利用すれば、mablでPRのテストを簡単に始めることができます。これらの統合は、あなたのチームがプッシュされたPRコードをテスト環境（通常はエフェメラルなもの）にデプロイすることを前提としています。必要であれば、mabl Linkで安全なトンネルを確立することができます。

また、別の方法を取ることもできます。PRのテスト環境が利用できない場合や、単にPRごとにmablクラウドでテストを実行したくない場合は、次のセクションで説明するように、ビルドプロセス中にmablランナーを使用し、ヘッドレスモードでテストを実行するようにコードリポジトリを設定することができます。

ビルド時のテスト

ローカルやmablクラウドでのテスト実行に加えて、mabl Runnerを使用すると、コードビルド中にCI環境内でヘッドレスモードでエンドツーエンドテストを実行することができます。これにより、アプリケーションをテスト環境にデプロイしなくても、開発ライフサイクルの早い段階でエンドツーエンドテストのフィードバックを得て、シフトレフトすることができます。テストとテスト対象のアプリケーションは、どちらもCIコンテナや仮想マシン（VM）の中で実行されます。

📘

アーリーアクセスプログラム

mabl Runnerは現在、アーリーアクセスプログラムの一環として、一部のお客様に提供しています。ご興味のある方は、こちらからリクエストしてください。

mabl Runnerとの主な違いは、これらのテストがCI/CDインフラストラクチャの中で実行されることです。クラウドでの実行とは異なり、mabl Runnerのテスト実行はChromeに限定され、自動修復やリッチな診断成果物（例：スクリーンショット、HARファイルなど）は生成されず、結果はmablアプリに保存されません。一方、CI実行は効率的で、一般的にはクラウドでのテスト実行にかかる時間の数分の1で完了します。mabl Runnerとクラウド実行のより詳細な比較については、テスト実行の概要ページをご覧ください。

mabl Runnerを使い始めるには、CI環境でテスト実行するをご覧ください。