バッチ処理のTDD：実行方法

RoRなどの「赤/緑/リファクタリング」などは問題ありません。

私の仕事は、Pythonや他のカスタムツールでサードパーティからの非常に大きなファイルをバッチ処理することです。

これらのファイルの属性に対するチャーンは高いため、かなり頻繁に適用される多くの修正/拡張機能があります。

期待される結果を備えた既知のテストデータによる回帰テストは存在しません。最新のテストケースが手作業でコーディングされた最後のバッチに対して最も近いものが実行され、爆発しないことを確認してから、スポットチェックと統計テストを適用して、データがまだ正常に見えるかどうかを確認します。

Q >> TDDの原則をこのような環境に取り入れるにはどうすればよいですか？

参考までに：単体テストはTDDと同等ではありません。TDDは、単体テストが要素であるプロセスです。

とはいえ、単体テストの実装を検討している場合、できることはいくつかあります。

すべての新しいコード/拡張機能がテストされます

この方法では、既に存在するすべてを単体テストする必要がないため、単体テストを実装する最初のハンプははるかに小さくなります。

個々のデータをテストする

大量のデータを含む可能性のあるものをテストすると、多くのエッジケースやテストカバレッジのギャップが生じる可能性があります。代わりに、0、1、多くのオプションを検討してください。0個の要素、1個の要素、および多くの要素で「バッチ」をテストします。1つの要素の場合、その要素のデータが含まれる可能性のあるさまざまな順列をテストします。

そこから、エッジケース（個々の要素のサイズの上限、およびバッチ内の要素の量）をテストします。テストを定期的に実行し、長時間実行されるテスト（大規模バッチ？）がある場合、ほとんどのテストランナーは分類を許可するため、これらのテストケースを個別に（夜間に？）実行できます。

それはあなたに強力な基盤を与えるはずです。

実際のデータを使用する

あなたが今やっているように、以前に使用した「実際の」データを入力することは悪い考えではありません。整形式のテストデータで補完するだけで、特定の障害点をすぐに知ることができます。実際のデータの処理に失敗した場合、バッチプロセスの結果を検査し、エラーを再現する単体テストを作成してから、有用なリグレッションケースでレッド/グリーン/リファクタリングに戻ることができます。

他の環境と同じです。

ロジックを最小レベルの粒度に分離します。これにより、プロセスの一連のルールが提供されます。各ルールは、プロセスに必要なロジックの1つの項目をカバーします。

次に、各ルールのテストを作成します。これらのテストは失敗します。テストを修正するコードを記述します。

説明している既知のテストデータを使用した回帰テストは、単体テストではありません。それは統合テストであり、これはTDDとは異なります。TDDを使用すると、ファイルをロードできるかどうかをテストするための単一のテストがある場合がありますが、一般に、テストデータを含むデータファイルに実際に近い他のテストはありません。代わりに、モックオブジェクトを使用して特定のルールを実行するために必要なデータをシミュレートします。

適切なソフトウェア戦略から始めて、TDDを適用します。

（免責事項：「解約」またはTDD、あるいはその両方を誤解した可能性があります。）

「ダーティデータ」をバッチ処理するために推奨される戦略は、Specify-Triage-Executeです。

• 厳密で狭い方法でデータの仕様をドラフトしますが、着信データの大部分（たとえば、80％以上）をカバーします。この仕様1を呼び出します。
• レコードが仕様1を満たすかどうかを決定するトリアージモジュール（必要に応じて、TDD）を開発します。
  • モジュールが非常に高速に動作することを確認してください。
  • モジュールはtrue / falseを返す必要があります。すべてのルールを満たすか、満たさないかのいずれかです。
• 仕様1を満たすことがわかっているレコードを解析する実行モジュール（必要に応じてTDD）を開発し、顧客が必要とするタスクを実行します。
• すべての受信データにトリアージ1を適用します。
  • 結果は、レコードごとに1つのブール値です。これは基本的に、着信データを仕様1または不明に分割します。
  • 顧客が必要とするときはいつでも、仕様1データに実行1を適用します。
• 残りのデータの80％を許可するために、仕様1の規則を緩和します。この仕様2を呼び出します。
• トリアージ2の開発と実行2。仕様1を満たさないデータに適用します。
• 残りのデータが十分に小さくなり、毎日手動で処理できるようになるまで、必要なレベルだけ繰り返します。

効率のヒント：

レコードに関連付けられたすべてのトリアージ結果（履歴または現在）を保存します。最後の実行以降にトリアージモジュールが変更されていない場合は、古いデータで再実行する必要はありません。

「TDDを行う前に何を構築するかを知っておく必要があります」

Specify-Triage-Executeは、各レベルで要件を管理しやすくするための1つの方法であり、将来の成長を可能にします。

（これら3つのステップの標準の正しい用語を知っている人がいたら教えてください。答えを編集します。）