BDD プラクティスを組織に適用しようとしています。私が働いている銀行では、毎晩のバッチ ジョブが、実行中のバッチ ジョブと相互にデータをやり取りする巨大なオーケストレーション マルチシステム フローです。
テスト中、インタラクティブなオンライン テストはおそらくテスト シナリオの 40 ～ 50% にすぎず、残りはバッチ ジョブに組み込まれています。例として、テスト シナリオは次のようになります。
- 午後 10 時現在、私の普通預金口座の残高が 100 ドルだとすると、
- 毎晩のバッチが午後 11 時に実行される場合
- 次に、バッチ実行が終了した後の午前 3 時に戻ってきて、$0.001 の追加の未収利息があることを確認する必要があります。
- また、銀行の総勘定元帳には、未収利息 $0.001 のエントリが追加されているはずです。
ご覧のとおり、これは非常に非同期的なシナリオです。Cucumber を使用してトリガーする場合、午後 10 時までに 100 ドルの残高をアカウントに挿入するステップ定義をおそらく作成できますが、バッチ ジョブが午後 11 時に実行されるようにバッチをトリガーするために Cucumber を使用するのは現実的ではありません。通常、オペレータは Control-M などの独自のスケジューリング ツールを使用して実行します。そして、Cucumber を数時間待ってから、発生した利息を確認します。タイムアウトになるかどうかはわかりません。
これは 1 つのシナリオにすぎません。バッチ実行は銀行にとって非常にコストがかかるため、1 回のバッチ実行にできるだけ多くのシナリオを適用するよう常に取り組んでいます。また、定期預金期間の終了時の最終的な利息が正しいかどうかを確認するためだけに 6 か月のバッチを実行する必要があるエージング シナリオもあります (Cucumber をそれほど長く待たせて聞くことは絶対にできませんよね?)
私の質問は、BDD プラクティスがこれらのような大規模なバッチ シナリオに適用された例はありますか? これにどのようにアプローチしますか？
編集して、私が管理している分離されたテスト シナリオを実行することを目的としていない理由を説明します。
テスト レベルの 1 つで個別のシナリオを実行し (私の銀行ではシステム テストと呼んでいます)、BDD は実際にそのコンテキストで機能します。しかし最終的には、エンド ツー エンド環境全体 (通常は SIT) を持つテスト レベルに到達する必要があります。この環境では、複数のテスト シナリオを並行して実行することが条件であり、いずれのシナリオも環境を完全に制御することはできません。プロジェクトの範囲によっては、この環境で最大 200 個のアプリケーションを実行できます。そのため、インターネット バンキングなどの顧客チャネルではトランザクション シナリオが実行され、コア バンキング システムでは金利計算や自動送金などのシナリオが実行されます。総勘定元帳システムが環境内のすべてのアカウントを統合してバランスをとる会計シナリオもあります。
私がやろうとしているのは、BDD フレームワークを活用してテストの実行を自動化し、結果をキャプチャして、環境内のすべてを手動で追跡する必要がないようにする方法を見つけることです。