web-dev-qa-db-ja.com

Behat / MinkはCI / CDパイプラインのどこに適合しますか

だから私はBehat/MinkでBDDテストを行うプロジェクトを持っています。私が持っているシナリオではミンクを使用しているため、ミンクが実際にページをテストできるように、テスト可能なコードをデプロイする必要があります。

これらのテストがCI/CDパイプライン/ワークフローにどのように適合するのか疑問に思っています。現在、私たちのワークフローは、プッシュ、デプロイ、ステージングでの手動テスト、手動リリース、本番環境での手動テストと同じくらい簡単です。

私の頭の中では、通常のパイプラインについて次のワークフローを念頭に置いています。

  1. リポジトリにプッシュ
  2. CIサービスまたは独自のCIサーバー（Jenkins？）へのポスト受信フック
  3. CIサービス/サーバーの実行composerインストールし、テストを実行します
  4. 彼らが合格した場合、それは展開します

MinkがページをテストするためにURLを必要とし、新しいコードがテストに合格していないため、新しいコードがまだサーバー上にないことを考えると、展開前にステップ3がどのように発生するかはわかりません。

本番環境にデプロイする前にテストを実行する、behatに最適な一連のイベントを誰かが推奨できますか？.

phpcontinuous-integrationcontinuous-deliverybehat
1
Adam Copley

WebDriverテスト（この場合はMinkテストなど）は、対話可能なフロントエンド/ UIを提供するWebアプリケーションにとって不可欠です。これは、ユーザーの対話に応じたアプリケーションの動作についての信頼を与えるためです。それらがないと、アプリケーションの機能について同じ信頼を得るには、非常に時間のかかる方法でアプリケーションを手動でテストする必要があります。

一般に、ビルドをCIにプッシュする前に、テストをローカルで実行する必要があります。これを行うには、ローカルホストでサーバーを実行し、ローカルで提供されるページに対してテストを実行します。

これにより、フィードバックループを短くしてエラーをできるだけ早くキャッ​​チでき、開発のベースラインとしてあなたや他の開発者が依存しているリポジトリでコードが壊れている頻度を減らすことができます。

次に、それらをステージング環境で再度実行します。これにより、マシン上で実行されるだけでなく、構成の点で実稼働環境にはるかに近い環境でも実行できるという確信が得られます。

2つの環境（ステージングと本番）を持つパイプラインのワークフローは、次のようになります。

  1. 本当にきちんとしたコードを書く：D
  2. ローカルでテストを実行する（WebDriverテストを含む）
  3. すべてのテストが緑色の場合は、プッシュしてリポジトリに移動します
  4. 新しいビルドをステージング環境にデプロイする
  5. ステージング環境でビルドに対してテストを実行します（WebDriverテストを含む）
  6. すべてが緑色の場合は、新しいビルドを本番環境にデプロイします

お役に立てれば ：）

1
Bastian Stein