わかりやすく説明してもらえませんか？
---
http://www.atmarkit.co.jp/fdotnet/special/tdd/tdd_04.html
では、どんなときにTDDを採用すべきではないか。筆者の個人的な感想ということをあらかじめ断っておくが、恐らくオブジェクト指向のモデリングを重視して行うプロジェクトは、TDDと相性が悪いだろう。というのは、TDDではコードの重複を取り除き、リファクタリングを行っていく過程で、クラスが生まれたり消えたりするからだ。例えば、『テスト駆動開発入門』に出てくる例でも、クラスが生まれたり消えたりする過程が描かれている。もし、個々のクラスが存在することに必然性があり、個々のクラスが特定の役割を担うことが期待されるなら、コードの重複を取り除く、というような目的のために、クラスが生まれたり消えたりすることは受け入れられるものではないだろう。このような問題は、オブジェクト指向モデリングという技法を支持しない筆者のようなプログラマであればまったく問題はないが、もっぱらオブジェクト指向モデリングを通してプログラムの構造をイメージする「オブジェクト脳」の持ち主には厳しい制約かもしれない。
No.1
31
3
60pt
おそらく、
この点が相反する、といいたいのではないでしょうか。
この意見はあくまでもそのページに書いてあるとおり、その筆者の意見であり、ソフトウェア開発手法として合意されているものではないと思います。私の意見では、オブジェクト指向とテスト駆動は直行するものであり、相反するものではありません。ソフトウェア開発においては、様々な層、粒度、見方、考え方で分析する必要があり、何か一つの手法で充分ということはありません。
たぶん、テスト駆動というよりは、リファクタリングが肝なのではないでしょうか。テストを書いてテストをパスするように実装する、そのテストにパスする限りは実装を書き換えて構わない、この「書き換えOK」の部分が、オブジェクト指向モデリングに限らず他のどんな開発技法とも相反するように思えるのではないでしょうか。
3
2
1
1
1
90
81
なるほど。ありがとうございます。
オブジェクト指向のモデリングを重視して行うっていうのは、
「まず、UML書きながら分析して、クラス図をもとにコードを生成して・・・」のようなやりかたということですかね。