問題タブ [atdd]

バッチ ジョブの ATDD を書き込もうとしています。ジョブのシナリオは次のとおりです。DB をチェックし、7 日前に何らかのイベントが記録されている場合は、そのイベントを取得して再処理します。ここでは、それを処理するための前提条件は 7 日間です。再処理中、システムは複数のサービスと対話します。したがって、ここで ATDD を使用してこのシナリオを作成し、ジョブが正常に実行されたかどうかを確認する必要があります。つまり、ATDD は、作成日が 1 週間前の特定のデータを作成する必要があります。私は Cucumber+Java を使用した ATDD で十分な経験があるので、同じ作業をしたいと思っています。誰かがそれを達成できるかどうかについて考えを与えることができますか?

cucmber/Gherkin に複数の関連フィールドを含む REST 応答を検証するためのベスト プラクティスは何ですか? シナリオのアウトラインを使用しているため、例のテーブルでパラメータ化されています。

私が検討したいくつかのアプローチを次に示します。

最も簡単な方法は、各フィールドをサンプル テーブルの列として追加することです。しかし、例の表が画面の幅を超えたため、これはすぐに非常に読みにくくなり、フォームの各シナリオでほぼ 10 のステップが必要になりましたAnd the <fieldName> should be <value>。これは非常に冗長であり、明らかに自然言語に似せようとする Gherkin の精神から逸脱しています。

次に、応答本文全体を JSON 形式のファイルに入れ、次のように 1 つのステップで検証することを検討しましたAnd the response matches <file containing expected response>(例の表には、ファイルへのパスが含まれているだけです)。ただし、これにより、実際のフィールドとデータ値が別のファイルに隠されているため、テストで検証しているものとまったく同じように非常に不透明になります。さらに、テスト ステップではデータの正確な形式 (JSON、XML など) を気にするべきではないことを読みました。

その後、この記事では、ステップの後に垂直テーブルを使用して複数のフィールドを指定することを読みました。次のような結果になります。

ただし、これをパラメーター化する方法がわかりませんでした。個々の原子値は例のテーブルの列に入りますが、他のテーブル全体はどうなるでしょうか? ネストされたテーブルがサポートされているかどうかを調べましたが、一部の人々はそれが判読不能であり、悪い習慣でもあると信じているようです。

では、このシナリオの一般的なベスト プラクティスは何ですか? パラメータ化されたシナリオの場合、自然言語の読みやすさと期待を正確に伝えることとの間で最もバランスのとれたアプローチはどれですか?