私は MVCStoreFront アプリで Rob Connery の Web キャストを見ていました。
public Decimal DiscountPrice
{
get
{
return this.Price - this.Discount;
}
}
次のようなテストがあります。
[TestMethod]
public void Test_DiscountPrice
{
Product p = new Product();
p.Price = 100;
p.Discount = 20;
Assert.IsEqual(p.DiscountPrice,80);
}
私はすべて単体テストに賛成ですが、この形式のテスト ファースト開発が本当に有益かどうか疑問に思うことがあります。たとえば、実際のプロセスでは、コードの上に 3 ～ 4 層があります (ビジネス リクエスト、要件ドキュメント、アーキテクチャ ドキュメント) 、実際に定義されたビジネス ルール (割引価格は価格 - 割引) が誤って定義されている可能性があります。
その場合、単体テストは何の意味もありません。
さらに、単体テストは別の障害点です。
[TestMethod]
public void Test_DiscountPrice
{
Product p = new Product();
p.Price = 100;
p.Discount = 20;
Assert.IsEqual(p.DiscountPrice,90);
}
今、テストに欠陥があります。明らかに単純なテストでは大したことではありませんが、複雑なビジネス ルールをテストしているとしましょう。ここで何を得るのですか？
保守開発者がアプリケーションを保守している 2 年間、アプリケーションの寿命を早送りします。ビジネスがルールを変更し、テストが再び失敗し、一部の新人開発者がテストを誤って修正しました...ここで、別の障害点が発生しました。
私が見ているのは、より多くの可能性のある障害点だけであり、実際に有益なリターンはありません.割引価格が間違っていても、テストチームは問題を見つけます.ユニットテストはどのように作業を節約しましたか?
ここで何が欠けていますか？今のところ、TDD を有用なものとして受け入れるのに苦労しているので、TDD を愛するように教えてください。プログレッシブであり続けたいので、私もそうしたいのですが、それは私には意味がありません。
編集: テストが仕様の強制に役立つと何人かの人々が言及し続けています。多くの場合、仕様も間違っていたというのが私の経験ですが、仕様を書くべきではない人によって仕様が書かれている組織で働く運命にあるのかもしれません。