私は C# 4.0 とのコントラクトを使用していますが、以前は多くの単体テスト (TDD ではありません) を使用していました。DbC によって、外部単体テストを作成する必要がなくなるのでしょうか?
個人的には、コントラクトはコード自体と密接に結びついており、その他の利点があるため、堅牢なフレームワークを作成するにはコントラクトの方が適していると思います。
皆さんはどう思いますか?
私は C# 4.0 とのコントラクトを使用していますが、以前は多くの単体テスト (TDD ではありません) を使用していました。DbC によって、外部単体テストを作成する必要がなくなるのでしょうか?
個人的には、コントラクトはコード自体と密接に結びついており、その他の利点があるため、堅牢なフレームワークを作成するにはコントラクトの方が適していると思います。
皆さんはどう思いますか?
私はそれが逆であると主張します-ユニットテストは、コントラクト構造によるプログラミングよりも望ましいです。
私がそう言うのは、PoC チェックは多くの場合、本番環境で自由にオフにできるアサートとして表現されるからです。(Eiffel でさえ、PoC のサポートが組み込まれている Bertrand Meyers の言語であり、本番環境ではそれらをオフにすることを推奨しています。)
「ハッピー パス」、例外、およびエッジ条件をテストする完全な単体テスト スイートが必要です。PoC とは異なる方法でリファクタリングする場合に役立ちます。
DbC は、単体テストで一般的にできることの一部を検証するのに役立つと思います。
DbC を使用すると、メソッドの入力/出力の検証などに効率的であり、時間を節約できます。
ただし、より複雑な検証(依存関係のモックなど) の場合は、外部単体テストを使用すると簡単になります。
したがって、それらを使用してすべての外部単体テストの必要性を排除できるとは思いません。