Cucumber-js: 結果にシナリオとタグがありません

いいえ。 テストケースのタグに簡単にアクセスすることはできません。 以前のシナリオの結果に戻る予定はありません。 タグが必要なユースケースは何ですか？

私の場合、タグシステムに依存しています。 アフターフックでいくつかのデータを取得するため。

このようなもの：

<strong i="7">@SuiteName</strong> <strong i="8">@SuiteSectionName</strong> <- These tags tell the suite
Feature: 

<strong i="9">@TC1563697</strong> <- This tag identifies the testcase in the test management tool <strong i="10">@New</strong>
Scenario: 
    Given  
    When 
    Then 

特定のタグが付いたシナリオでのみ実行されるフックを作成できます： https ：

シナリオタグを知るためのいくつかのユースケースもあります。 次のsudoの例を考えます（1.3.1のテストケースがあるため、バージョン構文が少し欠落しており、最新の3.0.1を調べています）。

<strong i="6">@set_video</strong> <strong i="7">@youtube</strong>
Scenario: User should see youtube video

<strong i="8">@set_video</strong> <strong i="9">@vimeo</strong>
Scenario: User should see vimeo video


this.After({tags: @set_video}, function (testCase) {
  let tags = testCase.scenario.tags;

_.forEach(tags, (function (tag) {
 if(tag === '<strong i="10">@youtube</strong>') {
   setVideo('youtube');
 }
if(tag === '<strong i="11">@vimeo</strong>') {
 setVideo('vimeo');
}
});

}

フックをいつ実行するかを示すタグが1つあり、フックをより動的にして他のユースケースで機能するようにするデータとして機能する他のタグがあります。 それ以外の場合は、同じロジックで同じフックを作成し、渡すデータのみを変更することになります。 タグを知っていると、フックをより柔軟にするための非常に便利で強力なツールであることがわかります。

3.0.1のAfterフックで結果オブジェクトを取得できないようです。 testCase、scenarioResult、scenarioを試してみました。 私は何かが足りないのですか？

テストケースをTestRailに保存し、実行前にダウンロードして機能ファイルとして保存する場合があります。

次に、アフターフックで詳細なテスト結果をSQLデータベースに送信します。 これらの結果は次のとおりです。

• TestRailの機能ID-タグから取得（各機能は機能IDのタグを自動的に生成します）
• スローされた例外-キュウリ1.xのscenario.getException()から取得
• 機能がタグ付けされているすべてのタグ
• 失敗したステップ- stepResultフックを使用して、すべてのステップの結果を取得します
• タグから取得した機能IDを使用してTestRailから取得したその他の情報の束

したがって、キュウリ3.xの現在の変更では、インフラストラクチャが完全に破壊されるため、切り替えることができなくなります。

@pawelus私のインフラストラクチャはまったく同じことをします。
これらのアクションを非同期で実行しても何も失われないため（つまり、実際のテストインフラストラクチャはTestRailの更新を「気にしない」ため）、そのコードをカスタムフォーマッターに移動して、イベントからの情報を使用できるようです。レポートを作成して送信するためのプロトコル。

個人的には、キュウリを起動するラッパースクリプトがあります。
キュウリが起動する前にTestRailシナリオをダウンロードするので、TestRailレポートコードをキュウリフックからラッパースクリプトに移動することは大きな問題ではありませんでした。
cucumberが完了すると、スクリプトは出力されたcucumberResults JSONを読み取り、そこから必要なすべての情報をコンパイルします。

どちらの方法でもコードを再配置する必要があるようです。
すべての事前/事後アク​​ションをラッパースクリプトに移動することは、V3で失った制御の一部を復元する優れたソリューションだと思います。
出力された結果を充実させるために重要なコンテキスト情報をシリアル化する必要があるため（関連するコードが実行されるまでにインフラストラクチャの状態が破壊されるため）、それでも多少苦痛ですが、それは実行可能です。

フックのタグを知る能力を失うのは残念だと思います。 パラメータを渡すことができないため、もう少し構成可能にする唯一の方法でした。タグを追加して、現在のシナリオに適用されたものを確認して、さまざまな入力で関数を呼び出しました。

@yaronassaは、分度器を介してテストを実行します。キュウリを直接起動しないため、ここで数える抽象化レイヤーがさらにあります。

分度器が起動する前に機能をダウンロードしますが、データベースに結果を送信するのは別の話です。

Seleniumグリッドでシャーディングとテストを実行し、失敗した機能を再実行すると、データベースで正しい順序で結果を取得するのは非常に面倒で複雑なロジックになります。 キュウリ1と2で持っていた機能を復元するためのかなりの量の作業。

また、ステップの結果を得るためだけにカスタムフォーマッターを作成することは、正しく聞こえません。

ねえ、私はあなたと一緒です。
キュウリの現在の状態（プロパティコレクション全体を含む機能、シナリオ、ステップ）への無制限のアクセス、および書き込みアクセスが必要でした（シナリオの将来の「呼び出しスタック」へのアクセスも必要であり、事前に操作することができます）。 ）。

cucumberJSがこの種の「内部の可視性」から意図的に離れているのを見て、私は近い将来に機能すると思う種類のソリューションを提供しています。 個人的には、私たちのようないじくり回しが、この種のアクセスを維持するために、Cucumberの内部の内部メソッドをオーバーライドすることに頼らなければならない時が来ると思います。
そして、それは大丈夫です-私たちの数は十数人で、何千人ものカジュアルユーザーがいると思います。

可能であれば、シナリオの名前も裏付けます。 実際、スナップショット機能を追加しています。スナップショットに名前を付けるには、シナリオの名前を知っている必要があります。

@ gd46次のことができます：

this.After({tags: "<strong i="7">@set_video</strong> and @youtube"}, function () {
  setVideo('youtube');
})

this.After({tags: "<strong i="8">@set_video</strong> and @vimeo"}, function () {
  setVideo('vimeo');
})

@set_videoフラグ以外に重複はありません。

@pawelus

次に、アフターフックで詳細なテスト結果をSQLデータベースに送信します。

Afterフックでこれを行う必要がありますか？ テストが終了した後、jsonフォーマッターの結果を解析してこれを行うことができますか？ これを続行するには、イベントプロトコルフォーマッタを使用できますが、結果が発生したときに、さらに処理が必要になります。 3.xの変更の副産物は、解析結果がサポートファイルからスタンドアロンプ​​ロセスに移動することです。 これは物事のより良い分離であり、理想的には物事が最初にどのように構築されたかであると思います。

@bnadim

attach関数を使用してスクリーンショットを追加し、イベントpotocol / jsonフォーマッターで出力してから、後処理を行ってシナリオ名に基づいてファイルに保存することができます。 サイドではありません：シナリオのURIと行番号が一意であるのに対し、シナリオ名は一意であることが保証されていません。

@charlierudolphそれは私のニーズに対する確かな代替ソリューションだと思います。 また、現在実行中のシナリオを分析する必要がなくなります。 特定の関数がフック内で処理できるさまざまな組み合わせを説明するフックのいくつかの組み合わせを定義することにつながる可能性があります。

たとえば、現在実行中のシナリオタグを取得してパターンに基づいてタグを分割し、一致の一部を関数のパラメーターとして使用する同様の例があります。 これらの場合、実行する必要のあるすべてのステップは同じであり、変更されるのはパラメーターだけです。 したがって、これによりフックのいくつかのセットアップ手順が削減され、複数のケースで機能するようになります。

そのような例の1つ：

tags: <strong i="9">@clear_w2OnlyUser</strong>, <strong i="10">@clear_w2OnlyArcotEnableUser</strong>

I split based on <strong i="11">@clear_</strong> and grab the second half as the parameter. tagName coming from the old scenario result of getTags, getName. 

let profileToClear = tagName.split('<strong i="12">@clear_</strong>')[1];

browser.waitForAngularEnabled(false);
browser.get(url);
login();
navigate();
deleteProfile(profileToClear);

これについてのあなたの考えを教えてください。 あなたの例は、場合によっては簡単に置き換えることができると思います。 しかし、発生する必要のある追加の手順がいくつかある他の場所では、これらすべての手順が重複する可能性があります。

私のユースケースは、どのように動作するかを知っているタグに基づいて、シナリオごとにモックサーバーをセットアップすることです。 特定のタグ付きシナリオにフックを追加すると、サポートするシナリオごとにフックを追加する必要があるため、メンテナンスが非常に多くなります...

また、シナリオの名前をログに記録するために、BeforeフックとAfterフックでscenario.nameを使用しています。 このようにして、テスト結果を分析するときに、特定のシナリオがいつ開始および終了するかを確認できます。 この変更はその機能を壊します。

私はCucumber-jsを使用してSeleniumを駆動しています。 ローカルとBrowserstackの両方

私は多くの重要なことのためにフックでテスト状態（機能、シナリオ、タグ、結果など）を使用していました。

• URLのシナリオ固有の変更を行う
• 現在のブラウザ構成に基づいてテストを動的にスキップします
• シナリオ固有のURLを使用して、テスト結果をBrowserstackに記録します
• 機能名とシナリオ名を使用して、Browserstackでセッション名を生成します
• タグを解析して、シナリオ固有のブラウザー解像度を識別および設定します

これらはすべてアプリにラップされ、同時インスタンスが全体の実行時間を短縮できるようにしました。

なぜこれらが落とされたのですか？
彼らは二度と戻ってこないのですか？

@ gd46

実行されているシナリオには、そのタイプのプロファイルが含まれていますか？ シナリオに、どのタイプのプロファイルが世界と相互作用しているかを保存させてから、保存されたプロファイルの削除を促す単一のクリアタグを作成することができますか？

@justusromijn

模擬サーバーの場合、セットアップをタグベースから、セットアップとは何かを定義するステップを使用して移動できますか？ 次に、簡単にパラメータ化できます。

@Jordyderuijter

シナリオ行とURIをログに記録できます（これは実際には一意であり、シナリオ名を検索する必要がありません）。

@leggebroten

URLのシナリオ固有の変更を行う

代わりにこのためのステップを使用するか、一意のタグを使用できます

現在のブラウザ構成に基づいてテストを動的にスキップします

どのように動的にテストをスキップしましたか？ ＃912はこれのサポートを追加します

シナリオ固有のURLを使用して、テスト結果をBrowserstackに記録します

名前の代わりに行とURIを使用できます。 前述のように、行とURIは一意であることが保証されていますが、名前は一意ではありません。 また、テスト結果のためにjsonフォーマッターまたはイベントプロトコルフォーマッターフォーマッターを解析し、何かを追加する必要がある場合は添付ファイルを使用することをお勧めします。

機能名とシナリオ名を使用して、Browserstackでセッション名を生成します

行+ URIを使用できます

タグを解析して、シナリオ固有のブラウザー解像度を識別および設定します

これにはステップを使用できます。

これらすべての例から、フックにタグまたは名前を追加する必要があると私に納得させるユースケースはまだありません。 タグと名前を付けることで、特定のことが簡単になりましたが、私にとってより意味のある方法は他にもあると思います。

@charlierudolph返信ありがとう

@charlierudolph返信ありがとうございます。

ステップの使用と出力の解析に関する提案は機能する可能性がありますが、コールバックがテスト状態にアクセスできる以前のバージョンよりもはるかに劣っています。

0）オブザーバーパターンと矛盾します。 コールバックには、サポートしている動作に必要なデータを提供する必要があります

1）極端な脆弱性を誘発します。 テストは信頼できるものでなければなりません。そうでないと、テストは信頼されません。 行番号とファイル名が変更されます。 キャリッジリターンを追加または削除するだけで、テストが失敗します。

2）ステップを使用して状態を変更すると、DRYに違反します。 タグでマークされたA / Bテストを追加する頻繁なケースを考えてみましょう。 コマンドライン拡張機能を追加して、含まれているステップに基づいてテストを実行しない限り、テストにはタグとそれをサポートする状態変更ステップの両方が必要になります。

3）開発者は追加の作業を行う必要があります。 状態を見つけるために出力を解析することは、不必要で、面倒で、エラーが発生しやすく、テストを出力形式にバインドし（結合度が低い）、DRYに違反します。

4）キュウリと矛盾している。 機能の状態を変更するためにステップ（テストのセマンティック部分）を追加することは、テストライターを分離するというCucumberの意図に反します。 動作が変更されていない場合、テストは変更されるべきではありません。

5）宣言型ではありません。 タグはテストに関するメタデータであり、タグを使用してテストが実行される状態を変更することは意味的に一貫しています。 一方、ステップはテストに組み込まれています。 一連のテストは、使用するステップではなく、タグによって識別されます。

ああ、私は実際には「スキップ」テストではなく、テストの実行を回避するためにcallback（null、 'pending'）を使用していました。 新しい「スキップ」機能は優れたソリューションです。

@charlierudolph 、私は考えていた、別の解決策..。
Worldオブジェクトを作成するときは、テストに使用されるScenarioオブジェクトへの参照を提供します。

Worldはすべてのコールバックで「これ」として使用できるため、V2との完全な同等性を実現します（AfterAllコールバックに結果が与えられた場合）

@leggebroten

1. キュウリのデザイン目標がオブザーバーパターンだとは聞いたことがありません。
2. シナリオ名も、1文字の変更でも変更されるため、壊れやすいものです。 無関係なアクションのように感じることを行うときは、ファイル/行番号の区切りに同意します。 テストの実行ではなく、結果のレポートに使用することを提案していたので、壊れやすい部分はあまり悪影響を及ぼしません。
3. Using Steps to alter State violates DRYわかりません。 タグは機能の選択に使用され、ステップはセットアップ/アクション/期待に使用されます。 これらは異なる目的です。 タグ付きフックを使用したセットアップにタグを使用するための最小限のサポートがありますが、複雑さを処理するようには構築されていません。
4. レポート用にフォーマッター出力を解析することだけを提案していました。 それはテストの実行に関係するべきではありません。
5. Adding Steps (a semantic part of the test) to alter the Feature's state is counter to intent of Cucumber of isolating test writer私もこれを理解していません。 手順を使用してアクションを実行したり状態を設定したりできない場合、どのようにテストを実行していますか？
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run 。 私はそれが一貫していることに同意しません。 私へのタグは、テストを識別するためだけのものです。 状態の最小限の変更はサポートされていますが、パラメーターを使用した複雑な状態の変更はサポートされていません。

システムにシナリオオブジェクトはもうありません。 v2との同等性を目標にすべきではないと思います。 この会話が出て、他の解決策を探していて良かったのですが、ユーザーがキュウリのインターフェースではなく実装にはるかに依存するようになったと思うので、以前の状態に戻りたくありません。

@charlierudolph 、

この問題についてお時間を割いていただき、ありがとうございます。 Cucumber-jsを提供するためにあなたが行った作業に心から感謝します。 しかし、現状ではV3にアップグレードできません。

私は戦闘するつもりはありません。 心配しているだけで、返事に出てくるかもしれません。

以前のバージョンの文書化されたイベントインターフェイスのみを使用して、オペレーティングシステム/バージョン、ブラウザー/バージョン、デスクトップ/を含む巨大で構成可能なテストマトリックス上で機能を同時に実行できるようにすることで、全体的なテスト実行時間を劇的に短縮するフレームワークを構築しました。モバイル、およびOptimizely A / Bテスト。

ステップを使用できません。 手遅れです。 デバイスタイプ、OS /バージョン、およびブラウザ/バージョンは、テストを開始する前に決定する必要があります。そうしないと、すべてのシナリオで「OSのセットアップ」ステップと「ブラウザのセットアップ」ステップが強制されます。 これは、キュウリの目標と直接矛盾しています。

または、前述したように、シナリオ情報（フィーチャURI、名前、行、およびタグ）をWorldコンストラクターに提供することもできます。 これは、Worldオブジェクトの意図と意味的に一致しており、カプセル化と拡張がより簡単です。 これにより、ほとんどのイベントハンドラーが削除されるだけでなく、ハンドラーの「this」がWorldオブジェクトであるため、オブザーバーパターンと一致する状態になります。

1. オブザーバーパターンがキュウリの設計目標であるとは言いませんでした。 フックとイベントはオブザーバーであり、そのため、仕事をするために必要な状態を与える必要があります。 このパターンにより、呼び出し元の実装とイベントハンドラーを分離できます。

2. 私は実際の名前に依存していません。 ただし、これらは一意であるため、Browserstackで関連するユーザーにとって意味のあるセッション名を作成する手段です。

3. Before中にタグのセットにアクセスできるため、テストを変更する（ステップを追加する）ことなく、状態を変更するための再利用可能な構造を構築できました（Optimizely URLパラメーターの設定など）。 これは、実行したいテスト（タグ）とそのセットアップの間に1対1の相関関係があることを意味しました。 ドライ。

4. 開発者が実装に依存するようになっていることに懸念を表明しましたが、必要なオブザーバーの状態を削除するソリューションは、開発者を他の実装（ファイル形式）に依存させることですか？ Stateプロパティにアクセスするよりも、ファイルの解析を面倒で遅く、エラーが発生しやすい方法でユーザーに強制する方が、どうすればよいでしょうか。

5. 明らかに、ステップはテスト状態を設定しています。 しかし、Cucumberの設計目標の1つは、ステップを作成する人を基礎となる実装から分離することでした。 EGは、基礎となる詳細にとらわれることなく、セマンティック動作をテストします。 クエリパラメータを変更するためのステップを追加し、デバイス/ブラウザ/ OSを定義することは、この目標に反しているようです。

6. あなたにとってタグはテストを識別することだけです。 しかし、 CucumberWikiにはタグの多くの用途があります。

7. 整理とグループ化
8. フィルタ（コマンドラインからセットを実行）
9. 関連ドキュメントへのリンク（Optimizelyフラグなど）
10. プロセスのどこに機能があるかを示します

コールバック前にタグにアクセスできることで、テストの実行に使用されているブラウザー構成に基づいて適切な状態を確認できます。 タグを使用すると、その宣言型になります。 ステップを使用すると、意図がわかりにくくなります

以前のバージョンのイベントハンドラーの呼び出しとパラメーターはインターフェイスでした。 開発者がコードと実装のリークを結合している場合は、読み取り専用の「シナリオ」プロキシをイベントハンドラーに渡します。

@charlierudolphお返事ありがとう

シナリオ名も、1文字の変更でも変更されるため、壊れやすいものです。 無関係なアクションのように感じることを行うときは、ファイル/行番号の区切りに同意します。 テストの実行ではなく、結果のレポートに使用することを提案していたので、壊れやすい部分はあまり悪影響を及ぼしません。

確かに、シナリオ名も壊れやすいですが、ファイルや行でシナリオを参照するよりも、シナリオを参照する方がはるかに壊れにくい方法です。 実行中の失敗を分析し、何が悪かったのかを確認するために、ログのシナリオ名を毎日使用しています。 ログにファイルと行番号のみが表示される場合、シナリオをさかのぼるにはオーバーヘッドが大きすぎます。 その上、誰かが機能ファイルに変更を加えたり、シナリオを別の場所に移動したりすると、これはさらに複雑になります。

ログにファイルと行番号のみが表示される場合、シナリオをさかのぼるにはオーバーヘッドが大きすぎます。

オーバーヘッドはどのように増えますか？ あなたはファイルと行番号を知っていて、そこに直接行くことができます。 シナリオ名がある場合は、そのファイルと行に移動する文字列を検索する必要があります。

オーバーヘッドはどのように増えますか？ あなたはファイルと行番号を知っていて、そこに直接行くことができます。 シナリオ名がある場合は、そのファイルと行に移動する文字列を検索する必要があります。

私が言ったように、その間に機能ファイルが変更され、シナリオがその行に配置されなくなった場合。 特に、古いテスト実行のログを調べている場合（たとえば、1週間前）。 この場合、私はgitを調べて、その時点でどのシナリオがその行にあったかを確認する必要があります。

FWIW、キュウリのルビーには、「簡単なことは簡単で、難しいことは可能である」という原則を満たしていると私が思う2つの拡張ポイントがあり、これらのユースケースに役立つアイデアかもしれません。

まず、 RunningTestCaseインスタンスを各フックに渡します。 これは、Gherkinソースに関するすべての情報（シナリオ/アウトライン/タグなど）に加えて、シナリオの現在の結果ステータスを含む不変の値オブジェクトです。 不変であるということは、ユーザーが私たちのことを変えようとする可能性がある場合を考慮する必要がないことを意味しますが、同様に、現在のプレイの状態について透明性を提供します。

次に、フィルターがあります。 フィルタを使用すると、テストケースのストリームを実行前に操作できます。 たとえば、フィルターを使用して、CLIで指定されたタグパターンと一致しないテストケースをストリームから削除します。 フィルタはパワーユーザー機能です。

HTH

フィルタのリンクの背後にあるドキュメントがひどいことに気づきました。 ごめん。 今すぐ修正する時間はありませんが、ここにいくつかの例があります： http ：

こんにちは@charlierudolph 、

この会話をフォローアップしてからしばらく経ちました。 あなたの声明について詳しく説明していただけますか？

「実行中のシナリオにはそのタイプのプロファイルが含まれていますか？シナリオに、世界と相互作用しているプロファイルのタイプを保存させてから、保存されたプロファイルの削除を促す単一のクリアタグを作成できますか？」

私がフォローするかどうかはわかりません。

そして、古いテスト結果なしで同じソリューションを取得する他の方法があるかもしれないことを私は理解しています。 しかし、この会話でこれまで見てきたことから、すべての選択肢は必要以上に複雑に見えるということです。 古いテスト結果には、実行しようとしているシナリオに関する記述データがたくさんあり、それが「パラメーター化された」フックを持つ唯一の方法でした。 私が見て試したものからの分度器は、現在、シナリオの行番号からの機能の実行をサポートしていません。 したがって、新しいtestCaseの結果には、ステータス以外に役立つものはあまりありません。

testCaseが、PickleFilterでgetTestCasesFromFileSystemを使用したときに返される結果と一致することを確認したいと思います。 私はこれを使用して、分度器にシャードとして渡すタグによるシナリオのフィルタリングをサポートするためのいくつかの興味深い並列作業を行いました。 その結果から返される情報ははるかに有用であり、testCaseの結果に含めることは非常に有用だと思います。

PickFilterの結果の例：

{ pickle: 
     { tags: [Object],
       name: 'Github test with page object',
       language: 'en',
       locations: [Object],
       steps: [Object] },
    uri: 'test/features/examples/github-example.feature' }

正確に一致する必要があると言っているわけではありませんが、この結果には、他の人や私が恩恵を受けているように見えることがたくさんあります。

私の例に興味がある場合は、ここで使用しています： https ：

@charlierudolphこれはtestCaseが設定されている場所ですか？

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/formatter/helpers/event_data_collector.js#L22

私が知ることができることから、testCaseと一緒にピクルスへの参照があります。 では、pickleの結果からtestCaseの結果にさらに数ビットを返してみませんか？

@ gd46わかりました。sourceLocationを置き換えるフックに渡されるオブジェクトにpickleを追加しましょう。 この関数で更新する必要があります： https ：

こんにちは@charlierudolph 、私はちょうどあなたのコメントを見ました。 それは素晴らしいことです！ これをすぐに見てみます。 喜んで貢献させていただきます。

@charlierudolph変更を明確にしたかっただけです。 sourceLocationのように、pickleに行番号が直接ないuriが含まれているという違いは問題ありません。 そして、行番号でURIを消費したい人は誰でも、pickleオブジェクトから返された行番号を使用できますか？ 確認したかっただけで問題はありません。

ソースロケーションオブジェクトを（削除するのではなく）そのままにして、pickleオブジェクトを追加しましょう。

わかりました、それは私にもうまくいきます。 だから私はキュウリに貢献するのは初めてです、私はまだ構造を理解しようとしています。

更新する必要がある行を指摘したように、sourceLocationの横に次のようなものを追加できると思います。

pickle: this.testCase.pickle

次に、フックでそれを消費したい人は誰でも次のようにそれにアクセスできます：

testCase.pickle.tags
testCase.pickle.name
etc. 

更新しましたが、関連するすべてのテストを更新する方法が100％わかりません。 ガイダンスを提供できますか？

フォークをローカルプロジェクトの1つへの変更とリンクすることで、変更をテストすることができました。 完全なtestCaseの結果は次のようになります。

{
  "sourceLocation": {
    "uri": "test\/features\/examples\/example.feature",
    "line": 4
  },
  "pickle": {
    "tags": [
      {
        "name": "@example",
        "location": {
          "line": 3,
          "column": 3
        }
      }
    ],
    "name": "Custom Transform should take belly and capitalize it",
    "language": "en",
    "locations": [
      {
        "line": 4,
        "column": 3
      }
    ],
    "steps": [
      {
        "text": "I have cucumbers in my belly",
        "arguments": [

        ],
        "locations": [
          {
            "line": 5,
            "column": 10
          }
        ]
      }
    ]
  },
  "result": {
    "duration": 7,
    "status": "passed"
  }
}

さらにテストを行った後、test_case_runnerでアクセスできる時点で、pickleにuriが含まれていないことに気付きました。 したがって、ソースの場所をそのままにしておくのは問題ないと思います。

PickleFilterはpickleを次のように返します。

{
    "pickle": {
      "tags": [
        {
          "name": "@example",
          "location": {
            "line": 3,
            "column": 3
          }
        }
      ],
      "name": "Custom Transform should take belly and capitalize it",
      "language": "en",
      "locations": [
        {
          "line": 4,
          "column": 3
        }
      ],
      "steps": [
        {
          "text": "I have cucumbers in my belly",
          "arguments": [

          ],
          "locations": [
            {
              "line": 5,
              "column": 10
            }
          ]
        }
      ]
    },
    "uri": "test\/features\/examples\/example.feature"
  }

したがって、URIが含まれていないピクルスを除いてすべてが同じになります。

これまでの変更点を強調するためにPRを開きました。 まだテストを更新する必要があります。

テストの更新に取り組んでいます。 ローカルのJavaバージョンを変更するためにこの設定を行ったところ、いくつかの機能テストを実行できなかったことがわかりました：/。

このスレッドは、閉じられた後に最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、新しい問題を開いてください。