まず結論から
-
Cypress を選ぶのは テストを自分たちのリポジトリに置き、チームが日常的に書いている言語で記述したい場合、他に類を見ないデバッグ体験を求めている場合、そしてテストを作成し維持していく余力がある場合です。
-
TestSprite を選ぶのは ボトルネックがテストの記述ではなく、何をテストするかの判断とスイートを生きたまま保つことにある場合です。特に、コードの多くがコーディングエージェントから、誰もレビューしきれない速さで届くときに当てはまります。
-
両方を運用するのは すでに残す価値のある Cypress スイートがある場合です。チームが意図して書いたフローはそのまま Cypress に任せ、誰も作成する時間のない広い範囲をエージェントによる検証でカバーします。
率直に言えば、これはキャパシティと制御のトレードオフです。Cypress は完全な制御を与える代わりに、作成と維持を求めます。エージェントは作成の手間なしに広さをもたらす代わりに、すべての手順を自分で書いたわけではないという事実を受け入れることを求めます。
並べて比較する
| 観点 | Cypress | TestSprite |
|---|---|---|
| 位置づけ | コードを書いてテストを記述するテストフレームワークおよびランナー | 稼働中のアプリケーションに対してテストを計画・実行し、失敗を切り分けるエージェント |
| テストを書くのは誰か | 自社のエンジニアが JavaScript または TypeScript で記述 | ソースから生成され、その後に自然言語で調整される |
| テストの置き場所 | リポジトリ内。他のコードと同じようにレビューされる | プロジェクト内。各テストの過去の実行結果を参照できる |
| デバッグ体験 | 非常に優れている。タイムトラベル、ライブリロード、使い慣れたツール群 | 実行の記録と、どこで食い違ったかを説明する失敗バンドル |
| UI が変わったとき | セレクタが壊れ、誰かが直すことになる | 手順が意図として表現されるため、見た目の変更はたいてい影響しない |
| 継続的にかかるコスト | 作成と維持。スイートの拡大に伴って増えていく | レビューと調整。増え方はより緩やか |
| 適しているチーム | QA の余力があり、コードで書くことを好むチーム | 専任の QA がおらず、エージェントが書いたコードをリリースしているチーム |
| 苦手なこと | 広さ。誰かが書いた範囲しかカバーできない | 個々の手順を細かく制御すること |
Cypress のほうが本当に適している場面
エージェントに手を伸ばすのが誤った判断になるケースもあり、それを明示しておく価値があります。
コンポーネント単位のテスト。 コンポーネントを単独でマウントし、その挙動を検証するのは Cypress の領域です。ブラウザを操作するエージェントでは、粒度が合いません。
決定的で、セキュリティに関わるフロー。 正確な順序が重要であり、決してずれてはならない場合は、すべての手順が書き下され、レビューされたテストこそが適切な手段です。
実行可能な仕様としてのテスト。 スイートを、機能がどう振る舞うかについての正式な記述として使っているチームもあります。そうした文書は生成されるものではなく、人の手で書かれるべきです。
すでに健全なスイートがある場合。 メンバーが信頼し、維持している Cypress スイートは資産です。ツールを統合するために丸ごと置き換えるのは、割に合う取引であることはめったにありません。
フレームワーク方式が行き詰まるところ
限界は技術的なものではなく、算数の問題です。すべてのテストは人が書かなければならず、人の数は固定されている一方で、機能の数はそうではありません。コーディングエージェントが、誰も読み切れない速さで変更を生み出し始めると、スイートは最も必要とされるまさにその時点で後れを取ります。
最初に現れる兆候は 2 つです。ひとつは、カバレッジが「書いていて面白かったフロー」に集中することで、そうしたフローはたいてい壊れるフローではありません。もうひとつは、各スプリントに占める保守の割合がじわじわ上がり、やがて誰かが不安定なテストを削除しようと言い出すことです。スイートはこうして死んでいきます。
作業を重複させずに両方を運用する
実際にうまくいく分け方は、そのテストが存在すべきだと誰が決めたかによる分担です。
Cypress に残すもの
コンポーネントテスト。
正確な手順そのものが契約の一部になっているフロー。
人が意図して腰を据えて仕様化したもの全般。
エージェントに任せるもの
誰も作成する時間のない、画面全体にわたる広範なリグレッション。
コーディングエージェントから届いた変更の検証。
重要でありながら、誰のリストにも載らないロングテールのフロー。
どちらにも任せないもの
負荷・性能に関する作業。別の手段が必要です。
セキュリティスキャン。別の手段が必要です。
正しい結果を定義できないもの全般。
どちらも同じパイプラインから実行できます。Cypress はこれまでどおり CI ジョブ内で実行されます。エージェントによる検証は、パイプラインがすでに発行しているデプロイイベントを起点に起動できるため、新しいビルドが稼働した時点で開始され、結果をプルリクエストに書き戻します。どちらも相手の存在を知る必要はありません。
評価するなら、これを試してください
何を比較するにせよ、意図的に何かを壊し、それぞれのツールが何を報告するかを見てください。保存ボタンが実際には保存しなくなる、といった本物のリグレッションを入れたうえで、3 点を確認します。失敗するか。その失敗が実際の食い違いを言い当てているか。そして、修正にあたる人やエージェントが、その出力だけを手がかりに、経緯を再構成することなく作業を始められるか。アサーションに到達すらしなかった実行を成功と報告するツールは、唯一重要なテストに落第しています。
TestSprite が Cypress に加えるもの
Cypress が与えられないのは、作成の時間を費やさずに得られるカバレッジであり、TestSprite はそのためにあります。テストケースはソースと稼働中のアプリケーションから生成され、その後に平易な言葉で調整されるため、広さが「何人のエンジニアを割けるか」で決まらなくなります。
日々の利用では、ほかに 2 つの違いが効いてきます。手順は意図として表現されるため、ボタンの位置を動かすようなリデザインでビルドが赤くなることはありません。そして失敗は、何を試み、アプリが何をし、どこで食い違ったかを説明する形で届くため、人だけでなくコーディングエージェントにも扱えます。後者は、次第に重要な読み手になりつつあります。
両方を維持しているチームでは、分担は明確です。Cypress は、誰かが意図して仕様化したフロー、すなわちコンポーネントテストや、正確な順序が契約の一部であるものを担います。TestSprite は、広さと、エージェントが書いた変更の検証を担います。どちらも同じパイプラインから実行され、相手の存在を知る必要はありません。
Cypress のテストを移行する必要はありますか。
いいえ。両者は同じパイプラインから独立して実行されます。多くのチームは、信頼している Cypress スイートをそのまま残し、何かを置き換えるのではなく、広さを補うためにエージェントによる検証を追加しています。
TestSprite は実行可能なコードを書き出せますか。
はい。生成されたテストのソースは、出力したりファイルに書き出したりでき、編集すれば置き換えられます。ただし、書き出されたスクリプトはフローを通る 1 つの経路のスナップショットであるため、手で維持していく成果物としてではなく、確認や可搬性のために使うのが適しています。
デバッグは Cypress のほうが優れていますか。
自分で書いたテストについては、そのとおりで、しかも差は大きいです。Cypress のタイムトラベルは非常に優れています。ただし、自分が書いたわけではないフローがなぜ失敗しているのかを問う場面では話が変わり、食い違いを説明する失敗バンドルのほうが、コードを追うより役に立ちます。
不安定なテストについてはどうですか。
フレームワーク方式のスイートにおける不安定さは、たいていセレクタかタイミングの前提に起因します。意図として表現された手順は、前者の大部分を取り除きます。一方で、環境そのものが本当に不安定なことによる不安定さは取り除けず、それはどのツールでも同じです。
どちらが安く済みますか。
ライセンス費用ではなく、総コストで比較してください。Cypress は無料ですが、スイートを作成し維持するエンジニアの時間は無料ではありません。このトレードオフがどちらに有利に働くかは、ほぼ QA の余力があるかどうかで決まります。