このページでは、Jev を使った E2E の道具 jevcumber を試した結果を扱います。jevcumber は、Gherkin で書いた自然文の手順を Jev に解釈させ、Playwright で実行します。解釈した結果は lockfile に記録するので、2 回目からは API を呼ばずに同じ結果を再生できます。自作のテストで困った「結果が決まらない」「CI で回しにくい」の 2 点に、この仕組みが答えを持っているかを確かめました。
ネットで見つかる Jev の E2E の事例
2026-09-23 に探すと、Jev を E2E に使う公開リポジトリがいくつか見つかりました。どれも公開から日が浅く、評価が固まったものはまだありません。Jev に何をさせるかで、4 つの型に分かれます。
| 型 | 事例 | Jev がすること |
|---|---|---|
| 目的を渡して操作させる | playwright-jev・jev-frontend-qa | 画面の要素から、次の操作と対象を選ぶ |
| 自然文の手順を解釈させる | jevcumber | Gherkin の 1 手順を、操作の種類・対象・値に分解して選ぶ |
| 探索的テスト | JevTest | 次の一手を選び、結果が要件に反していないかも判定する |
| 実行するテストを選ぶ | jev-test-filter | git の差分を読み、各テストが影響を受けるかを採点する |
README を読むと、どの事例も最終的な合否はコードに決めさせています。playwright-jev は、Jev が「目的を達成した（DONE）」と答えただけでは合格にせず、決定的な事後条件を 1 つ以上書くよう勧めています。JevTest は、Jev が「おかしい」と判定したものを不具合と断定せず、候補として人の確認に回します。jev-test-filter は、confidence が低いテストは実行する側に倒しています。
Running a test that did not need to run costs seconds; skipping one that did costs a release.
出典: https://github.com/mizchi/jev-test-filter（取得日: 2026-09-23）
この中から jevcumber を選んだのは、lockfile で結果を固定する仕組みを持っているからです。
既読のシナリオを書く
jevcumber 0.2.1 を使い、ビルド済みのこのサイトを手元で配信して試しました。シナリオは、一覧の先頭にある コールスタックのノート で、1 ページ目を読み終えるとボタンが「続きから読む」に変わることを確かめるものです。
# features/read-state.feature
Feature: Read state
Scenario: Finishing a page marks it as read
Given I am on "/notes/9b49e49a-d84c-430e-92e9-4d66ccf21e8d"
Then I should see "今すぐ読む"
When I click "今すぐ読む"
Then I see the first page of the note, which explains what a call stack is
When I scroll the "次のページ" link into view
And I wait 1 seconds
And I go to "/notes/9b49e49a-d84c-430e-92e9-4d66ccf21e8d"
And I wait for the page to settle
Then the "続きから読む" link is visible
この形は、何度か書き直してたどり着いたものです。引用した文言（"今すぐ読む" など）は、Jev ではなく Playwright がそのまま探します。そのため、普通の E2E と同じつまずきがそのまま残りました。たとえば Then I should see "続きから読む" は、「文字が見えるか」と「リンクが見えるか」のどちらの意味か確率が割れて止まりました。「the "続きから読む" link is visible」と書き直すと通りました。スクロール直後に移動すると既読が付かないこともあり、待つ手順を 2 つ足しました。
説明で書いた手順（「コールスタックを説明する 1 ページ目が見える」）は、Jev が画面の見出し「コールスタックとは何か」を根拠に選び、その見出しに固定（pin）しました。2 回目からは、この見出しがあるかどうかを Playwright が確かめるだけです。
アプリを壊すと、再生で気づけるか
既読があってもボタンが「今すぐ読む」のままになるように壊し、--frozen で再生しました。
UI の変更に追従する（heal）
手順を文言の引用ではなく説明で書いておくと、文言が変わっても追従できます。「読み始めるボタンを押す」という意味の手順を書いて記録したあと、ボタンの文言を「今すぐ読む」から「読み始める」に変えました。
# heal/start.feature
Feature: Start reading
Scenario: Start reading a note
Given I am on "/notes/9b49e49a-d84c-430e-92e9-4d66ccf21e8d"
When I click the button that starts reading the note
Then I see the first page of the note, which explains what a call stack is
書けなかった判定
「1 ページ目に既読の ✓ が付いている」は、jevcumber では通りませんでした。アプリは正しく動いていて、画面には ✓ が出ています。
Jev に渡るのは画面の文字だけです。✓ がどの行に付いているかという構造が伝わらないためと考えていますが、確かめてはいません。こうした判定は、DOM を見るコードのテストのほうが確実です。
分かったこと
- lockfile を使えば、Jev を E2E に入れても結果は毎回同じになり、CI では API キーも要りません
- Jev が働くのは、手順を書いたときと UI が変わったときだけです。役割は「テストを書く手間を減らす道具」に近いものです
- 引用した文言は Playwright がそのまま探すので、普通の E2E と同じつまずきは残ります。自然文の手順は書き方で結果が変わり、通る書き方を探す手間がかかります
- 取り入れるなら組み合わせます。✓ のような画面の構造はコードで書くテストで確かめ、主要な導線は jevcumber で追う、という分け方です
試したのは 1 シナリオだけです。手順が増えたときにどれだけ手間が減るかは分かっていません。