複雑なデータを取得して変換する一連のコンバーターがあります。ほとんどの場合、入力は EDI で出力は XML、またはその逆ですが、他の形式もあります。
データには多くの相互依存関係があります。このような複雑な入力データを生成できる方法やソフトウェアはありますか?
現在、私たちは 2 つの方法を使用しています: (1) 主にファイルのバグとドキュメントのサンプルから長年にわたって構築してきた一連のサンプル ファイル、および (2) 疑似ランダム テスト データの生成。しかし、前者はほんの一部のケースしかカバーしておらず、後者には多くの妥協点があり、フィールドのサブセットのみをテストしています。
複雑なテーブル駆動型データ ジェネレーターの実装 (再発明?) に進む前に、どのオプションが成功したと思いますか?
さて、答えはあなたの質問にあります。複雑なテーブル駆動型データ ジェネレーターを実装しない限り、(1) と (2) を正しく使用していることになります。
(1) は、「1 つのバグが検証され、1 つの新しいテスト ケース」というルールをカバーしています。また、(2) の疑似乱数テスト データの構造が実際の状況に対応していれば問題ありません。
(2) は常に改善することができ、新しいエッジ ケースについて考えると、主に時間の経過とともに改善されます。テスト用のランダム データの問題は、テスト ケースのランダム データから期待される出力を計算するのが非常に困難になるポイントまでしかランダムにできないため、テスト ケースでテスト対象のアルゴリズムを基本的に書き直さなければならないことです。
したがって、(2) は常に一部のケースに一致します。ある日、すべてのケースに一致する場合、それは実際にはアルゴリズムの新しいバージョンになります。
報告されたエラーを再現することが不可能ではないにしても困難になる可能性があるため、ランダムデータを使用しないことをお勧めします（「疑似ランダム」と言ったことは知っていますが、それが正確に何を意味するのかわかりません）。
データのファイル全体を操作する場合、機能テストまたは統合テストを検討する可能性があります。既知のバグを含む一連のファイルを取得し、これらを単体テストに変換することをお勧めします。少なくとも、将来遭遇するバグについてはそうするようにしてください。次に、これらの単体テストを拡張して、「サンプルデータ」がない他の誤った条件のカバレッジを含めることもできます。これは、チェックしたい条件/ルール違反を考えるたびに、まったく新しいデータ ファイルを作成するよりも簡単です。
データ形式の解析が、形式内のデータの解釈からカプセル化されていることを確認してください。これにより、前述の単体テストがはるかに簡単になります。
テストを確実に実行する必要がある場合は、ファイル形式の機械可読な説明を取得し、形式を分析してそれに基づいて有効/無効なファイルを生成するテスト データ ジェネレーターを作成することを検討してください。これにより、ファイル形式と同様にテスト データを進化させることもできます。