Grafana はサイプレスのテスト結果を永続的な可観測性データに変換します

Grafana Labs は、テスト結果を Prometheus メトリクスに変換して Grafana Cloud に送信することで、Cypress テストスイートを監視するための実用的なアプローチを公開しました。このアプローチにより、チームは端末出力や個々の実行からの CI ログのみに依存するのではなく、複数の実行にわたるテストの失敗、実行時間、および不適合テストを追跡できるようになります。

このアプローチでは、Cypress ライフサイクルフックを使用してテスト結果をキャプチャし、Prometheus Pushgateway を使用して短期間のテストジョブからのメトリクスを一時的に保持し、Grafana Alloy を使用してそれらのメトリクスを収集して Grafana クラウドにプッシュします。結果のデータは視覚化されてアラートに使用され、テストスイートの動作を長期的に把握できます。

Cypress は、プラグインのライフサイクルを通じて有用な情報をすでに公開しています。 before:run フックは、テストスイートの実行全体に共通の識別子を確立できます。一方、after:spec は、成功と失敗の数、テスト状態、期間などの各仕様の結果を提供します。 Grafana の例では、この情報を、個々のテスト、仕様、完全な実行をカバーする小さな Prometheus メトリクスのセットに変換します。

これにより、チームは 1 回の CI 実行では答えるのが難しい質問に答えることができます。ダッシュボードには、特定の仕様が遅くなっているかどうか、テストが断続的に失敗し始めているかどうか、またはスイート全体のパフォーマンスが低下しているかどうかが表示されます。 GitHub Actions ランタイム識別子を値に付加することもできるため、値の変更をそれを生成した CI 実行まで追跡することができます。

Cypress の実行は有効期間が短いジョブであるため、Pushgateway は重要です。従来の Prometheus スクレイピングは、終了する前にテストプロセスに到達しない可能性があるため、結果は仲介者にプッシュされ、後で Alloy によってスクレイピングされる可能性があります。 Grafana は、このテレメトリをテスト結果の一部ではなく、テストの副作用として扱うことを推奨しています。値の公開に失敗しても、成功したテストが失敗することはありません。

このアプローチは、エンジニアリングチームが質の高いデータを扱う方法における広範な変化を反映しています。テスト結果は多くの場合、主にレポート作成のために CI システムまたはテスト管理プラットフォームに保存されますが、運用テレメトリは運用データとして扱われます。テスト実行値を同じ可観測性環境にエクスポートすると、アプリケーションとインフラストラクチャの動作とともにソフトウェアの品質を検査する機会が生まれます。

これは、個々の障害ではなく傾向を特定する場合に特に役立ちます。時折テストが失敗する場合、CI では単独の問題のように見える場合があります。ただし、永続的なメトリクスによって、障害率が増加していること、実行時間が徐々に悪化していること、または障害が特定の仕様または導入期間と相関していることが明らかになる場合があります。

また、このアプローチは、独自の Cypress 監視メカニズムを必要とするのではなく、意図的に既存のオープンソースコンポーネントに依存しています (Cypress → Prometheus Values → Pushgateway → Grafana Alloy → Grafana Cloud)。 Grafana のより広範な可観測性プラットフォームは、OpenTelemetry ベースのログ、トレース、その他のテレメトリとともに Prometheus 互換のメトリクスをサポートします。

専用のテスト管理ツールや CI レポートツールに代わるものではありません。 Cypress Cloud、Allure、Xray などのプラットフォーム、および GitHub Actions などの CI システムは、より豊富なテスト固有のビュー、実行履歴情報、または広範な開発ワークフローとの統合を提供します。 Grafana のアプローチは異なります。テスト結果を時系列の運用データとして扱い、エンジニアがシステムの動作を理解するためにすでに使用しているテレメトリと並行して利用できるようにします。

この区別は、チームが単純な合否レポートを超えて進むのに役立つ可能性があります。エンジニアリングチームは、最新バージョンが合格したかどうかをただ尋ねるのではなく、より広範なエンジニアリングの健全性指標の一部として、テストの実行時間、失敗率、不適合テストの頻度、スイートレベルのパフォーマンスなどの指標の追跡を開始できます。

より大きな意味は、自動テストがそれ自体で有用なテレメトリをますます生成していることです。テストスイートが大規模化して分散化が進むにつれて、この情報を長期的に保持して関連付けることで、チームが劣化を早期に特定し、CI ジョブの終了時に消える指標ではなく、テストの信頼性とエンジニアリングシステムのパフォーマンス特性を観察できるようにするのに役立ちます。