Guruでは知識共有を大切にしており、新しく役立つことを発見したら、世界に知ってもらいたいと思っています！ 私たちのエンジニアリングチームは、テストとQAプロセスにCypressを使用しています。 彼らはより良いバーンテストを実行する新しい方法を発見し、その新しく改善されたプロセスを他のエンジニアやテスターと共有したいと思っています。

昨年、私たちはテストカバレッジの向上に注力してきました。特に、コードの更新を行う際に、異なる部分が正しく機能することを確認するエンドツーエンドテストに焦点を当てています。 この種のテストでは、ユーザー行動をモックするCypressというツールを活用しています。 このテストスイートは、すべてのプルリクエストで実行され、新しいコードがUIの機能を壊していないことを確認しています。 私たちはまた、Cypressスイートが本番ブランチで失敗した場合にリリースが出ないようにしたいと考えています。

従来のテストで私たちが求めるもの

私たちが直面している問題の一つは、いくつかのテストが失敗することです。それはUIやコードとは関係のない理由で起こることがあります。 では、Cypressはこれらのケースでどのように助けてくれるのでしょうか？ 私たちはCypressを使って、ユーザーの行動を定義することができます。 いくつかの変数がCypressに失敗を伝える原因となることがありますが、ユーザーの視点からは何も問題がないように見えます。

例えば、「このウェブアプリに移動>新しいGuruカードを追加>作成後の状態が見えることを期待」といったテストがあるかもしれません。 もしカード作成の読み込み状態が少しでも遅れると、Cypressは作成後の状態を探し始めてテストが失敗することがあります（ほとんどの場合、このテストは合格します）。 もしプルリクエストで一度合格すれば、時折フレークする可能性のあるコードをマージすることができます。 しかし、それが本当にそうかどうかはわかりません。合格したテストは、コードが正しいという保証にはなりません。

このような状況は、テストカバレッジの信頼性を低下させます。 その結果、デプロイメントパイプラインでテストの失敗が発生した場合、UIに問題があるのか、テスト自体に問題があるのかを確認する必要があります。 これを解決するために、テストがデプロイメントコードブランチに移行する前に失敗する可能性を検出する方法を考えることにしました。

バーンテストの役割

バーンテストを導入します。 バーンテストは、より厳しいまたは過酷な条件下で物事をテストするためのプロセスです。 テストする方法や特定の領域によっては、ストレステストまたは負荷テストとも呼ばれます。

Guruでは、Cypressスイートの一部として、追加または修正されたテストにバーンテストを使用します。 これらのテストがマージされる前に、何度も連続して実行し、すべて合格する必要があります。そうしないと、CircleCIビルドパイプラインの次のステップに進めません。

このステップは、Cypressテストスイート全体を実行する直前に行われます。 この順序の利点は、バーンテストステップで失敗が発生した場合、早期に全体のチェックが失敗としてマークできることです。 スイートの残りをスキップすることで、時間を節約し、新たに導入されたテストがどれだけ信頼性と耐障害性を持っているかを確認するのに必要なサイクルを減らすことができます。

探しているファイルを見つけるために、現在のブランチでgit diffを使用し、その出力をツールcypress-repeatにパラメータとして渡すことで、指定した回数だけテストを実行し、バーンテストをエンドツーエンドテストスイートのステップとして追加します。

成果

テスト計画にこの調整を加えることで、かなり良い結果が得られました。 私たちにとって、バーンテストを追加することで、信頼性のないテストを見つけるのに最大30分の時間を短縮できます。  新機能を追加するためのターンアラウンドタイムも改善されます。 新たに追加されたテストが最初に実行されるため、残りのビルドプロセスを続行する前に安定性を確認できます。

全体として、テストプロセスをより効率的で堅牢にすることに引き続き注力することで、エンジニアリングチーム全体の新機能を迅速に出荷する自信が高まります。 私たちはバグをより早く修正し、すべてのコードベースでの作業を容易にしています。 この投稿が他のCypressユーザーがより良いテストを作成し、チーム全体がより効率的に作業を進めるのに役立つことを願っています。