cucmber/Gherkin に複数の関連フィールドを含む REST 応答を検証するためのベスト プラクティスは何ですか? シナリオのアウトラインを使用しているため、例のテーブルでパラメータ化されています。
私が検討したいくつかのアプローチを次に示します。
最も簡単な方法は、各フィールドをサンプル テーブルの列として追加することです。しかし、例の表が画面の幅を超えたため、これはすぐに非常に読みにくくなり、フォームの各シナリオでほぼ 10 のステップが必要になりましたAnd the <fieldName> should be <value>。これは非常に冗長であり、明らかに自然言語に似せようとする Gherkin の精神から逸脱しています。
次に、応答本文全体を JSON 形式のファイルに入れ、次のように 1 つのステップで検証することを検討しましたAnd the response matches <file containing expected response>(例の表には、ファイルへのパスが含まれているだけです)。ただし、これにより、実際のフィールドとデータ値が別のファイルに隠されているため、テストで検証しているものとまったく同じように非常に不透明になります。さらに、テスト ステップではデータの正確な形式 (JSON、XML など) を気にするべきではないことを読みました。
その後、この記事では、ステップの後に垂直テーブルを使用して複数のフィールドを指定することを読みました。次のような結果になります。
And the response contains:
| field1 | value1 |
| field2 | value2 |
ただし、これをパラメーター化する方法がわかりませんでした。個々の原子値は例のテーブルの列に入りますが、他のテーブル全体はどうなるでしょうか? ネストされたテーブルがサポートされているかどうかを調べましたが、一部の人々はそれが判読不能であり、悪い習慣でもあると信じているようです。
では、このシナリオの一般的なベスト プラクティスは何ですか? パラメータ化されたシナリオの場合、自然言語の読みやすさと期待を正確に伝えることとの間で最もバランスのとれたアプローチはどれですか?