2004年09月10日
アジャイルライブ時の質問について
アジャイルライブ終盤の質問タイムにて上がった質問の中に
「リファクタリングでコードを変えるということは、テストコードも修正しなくてはいけないのではないか?」
「テストファーストで書いたコードが間違っていたらどうするのか?」
というものがあった。
.NETでのテスト駆動開発(TDD本)を読んでると著者は前者について明確な回答を書いている。
コードをリファクタリングする際には、テストが最新の状態であることを確認してください。
要件の変化に応じてテストを変更する必要がある場合は、それを先に行なってください。
如何なる状況にせよ優先すべきはテストコードであるということでしょうか。
後者についてはこれはテストコードに限ったことではなく、ウォータフォールにおいても詳細設計が間違っていたらどうするんだ?ってことにもなるわけで、その解としてコミュニケーションを重視するプラクティスがあるわけなんだよな。
ただこの詳細設計とテストケースとの関係については俺自身も悩むところが多くて、例えばテストケースを書いていけば、それがクラスの仕様 (インターフェイス) を表すことになり、メソッドの機能フローを表現していることにもなる。
ならば詳細設計なんてドキュメントレベルで書かなくても、テストコードで代用しちゃえば良いのか?ってことになると極端な気がするし、なんか不安もある・・
まぁこの辺については「C#によるXP開発体験記」に書いてありそうな予感なので、まずはそれを読んでからだな。
にしても今更書くのもなんやけど、開発プロセスってのも真剣に考えはじめると.NETのアーキテクチャうんぬんと同等か、それ以上に深いよなぁ・・
Posted by GAMMARAY at 2004年09月10日 21:41
| TrackBack
TDDにおけるテストは多分に仕様をテストで表現するという面があると思います。このことは、Unitテストがクラスの利用者としてのテストを行っていることを意味します(もちろんPrivateなメソッドをテストしたくなる時もありますが)。
リファクタリングによってクラスが公開するインターフェースを変更してしまうこともあるでしょうが、その場合は、元の設計が間違っていた可能性が高いと思います。そのときは、TDDに基づき、テストからやり直すべきだと私は考えます。
>ならば詳細設計なんてドキュメントレベルで書かなくても、テストコードで代用しちゃえば良いのか?ってことになると極端な気がするし、なんか不安もある・・
FowlerもSbE(Specification By Example)について考えを述べていますね。彼のBlikiのこの部分の日本語訳が以下のサイトにあります。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?SpecificationByExample
ご教示ありがとうございます。
>TDDにおけるテストは多分に仕様をテストで表現するという面があると思います。
この点はやはりというか目から鱗でした!
仕様をテストで表現するというこで良いのかどうかの確信が一人で考えてると持てなくてちょっともやもやしておりました。
福井さんに言って頂けると自信が持てます。
であればやはりリファクタリングでインターフェイスが変われば、詳細設計の役割も果たすテストコードの修正は必然であるということですね。
URLは早速読破してみます!
貴重な情報ありがとうございます!!
>ならば詳細設計なんてドキュメントレベルで書かなくても、テストコードで代用しちゃえば良いのか?ってことになると極端な気がするし、なんか不安もある・・
ドキュメントよりコードのほうが正確に仕様を語れる、という考え方もありますね。
このあたりは、アジャイル系の開発方法論の話を読んでいくといろいろでてくるかと。
#本で読んだ知識しかないから、自分の言葉じゃ語れない(^^;
ソースはドキュメントよりも雄弁であるって考え方ですね。
とにかくTech・Edで購入した2冊のアジャイル本をじっくりと読んでみます。