0

各事後条件のテストが他の事後条件のテストと非常に似ている比較的複雑な方法を単体テストする最良の方法は何ですか? 事前条件は単独でテストするのは簡単ですが、事後条件をテストできるように、すべてが保持されるようにするために多くのセットアップが必要です。私が考えた方法は以下の3つです。

  1. 一度にすべてをテストできる一般的な関数を作成しますが、デフォルトは可能な限り単純なシナリオです。この関数は、最も単純なシナリオからの逸脱を示すフラグ パラメータを受け取ります。次に、事後条件 (または組み合わせ) ごとに、適切なフラグを指定してその関数を呼び出す単体テストを作成し、その事後条件のカバレッジを取得します。ここでの利点は、コードの重複がほとんどないことです。そのため、テスト対象のコードが変更された場合でも、1 つのテスト関数のみを書き直す必要があります。事後条件のグループをカバーするテストを作成するのは簡単ですが、一般的なテスト関数が非常に複雑であるという欠点があります。
  2. 最も単純なシナリオの単体テストを作成してから、コピー、貼り付け、および変更します。利点は、各テストが非常に単純であることです。欠点は、元のテストの問題を貼り付けるたびに修正する必要があることです。
  3. 関数をパラメーターとして受け取ることでさまざまな部分をオーバーライドできる一般的な関数を作成しますが、デフォルトでは最も単純なシナリオをテストします。フラグ付きの一般的な関数と同様の利点がありますが、すべてを噛み合わせると、より複雑になる可能性があると思います。

4 番目の選択肢は、「やり方が間違っている。テストするメソッドを、テストしやすいように分割してください!」というものです。

何か案は？

4

1 に答える 1

2

私の以前のコメントはやや冗談でした。

大まかに言えば、私が実際に提唱するのは、オプション 2 としてリストされていることを実行することですが、その後、テスト コードをリファクタリングして、コピーと変更の作業によって作成された重複を排除することです。

これをすべてテストしたら、本番コードをリファクタリングして、より小さく管理しやすい部分に分割し、それらの部分を再利用可能にする方法を探すことができます。しかし、大きな変更を行う前にテストを行うことは常に健全です。

于 2012-07-06T21:46:04.363 に答える