Uncle Bobとしても知られ、Agile Manifestoの共著者でもあるBob Martin氏は、TDDがアーキテクチャに悪影響を及ぼすかどうかについての評価を最近公開した。この議論の大半を、テスト駆動アプローチに従うことで高レベルの設計と実装コードの一般的な保守性の両方に否定的なインパクトがあるかどうかに割いている。Martin氏は、TDDは重要な訓練方法であるが、良い設計を導くのは疎結合、分離そして隔離といった原則であると結論づけている。
Martin氏の探求はテストは設計へのダメージを誘発することに関するものであり、このテーマはRuby on Railsの作者であるDavid Heinemeier Hansson氏が最初に提起したものである。本質的にはこれはHansson氏が好む設計と、Rubyのコントリビュータであり講演者であるJim Weirich氏が導入したよりテストしやすい設計との比較である。Martin氏はどちらの設計を好むか読者に結論を出すよう促しており、以下のように記している。
論争は詰まるところ分離と間接化です。良い設計に対するDHH氏の概念はこれらを最小化することであり、対してWeirich氏の考え方はこれらを最大化することなのです。
Martin氏は脆弱なテストプログラムに関しても触れている。これはちょっとした実装コードのリファクタリングがこれに依存する数多くのテストを破壊し、これらの全てを更新する必要に迫られる事態のことである。
Martin氏は自身の意見を明らかにするにあたり、彼はまさにプロダクションコードのようにテストコードも設計する必要があることを最初に指摘している。これはTDDに従うかどうかには関係がない。
テストに適用する設計の原則は通常のコードに適用するものとまさに同様です。テストはシステムの一部です。そしてそれらはシステムの他の部分の標準と同じもので維持されなければなりません。
Martin氏はTDDの良くある誤りについても説明している。それは、TDDがテストと実装の間に一対一の対応がある状態で終えるものである、というものである。これは１つの実装クラスに１つのテストクラスがあり、１つの実装メソッドに１つのテストメソッドがある、ということを意味しうる。このことの悪い影響としてテストと実装の密結合があり、リファクタリングや推理することが難しいコードを生み出すことに繋がる。
高レベルのアーキテクチャと設計に関しては、TDDから生み出されるものではないとMartin氏は考えている。
高レベルの設計とシステムのアーキテクチャがTDDから生み出されるという考えに関しては、率直に言うとばかげています。あらゆるソフトウェアプロジェクトのコーディングを始める前に、アーキテクチャに関する適切なビジョンを持つ必要があります。TDDはこのビジョンを生み出すつもりもなければ、可能でもないでしょう。
しかし、Martin氏はよりコードに近い、低レベルの設計はTDDの実践から生み出すことができると考えている。言い換えると、同じテストのまま、実装コードをリファクタリングし、より保守性の高い構造にすることは可能である。Martin氏はこれは２つの進化の流れを導くと考えている。"テストがより特殊性を持つにつれて、プロダクションコードはより一般化されます"
これらの差異にも関わらず、Martin氏の主な考えは、TDDは１つの訓練方法であるということである。彼は良い設計を生み出すのは開発者にかかっており、これはTDDを採用するかどうかには関係がないと結論づけている。
悪い設計を生み出すのはTDDではなく、良い設計を生み出すのがTDDであるというわけではないということがわかったでしょう。それはあなたにかかっているです。TDDは訓練方法です。仕事を系統立てる１つの手法です。テストカバレッジを保証する１つの手法です。特殊性に対応して適切な一般性を保証する１つの手法なのです。
まとめると、彼の見方によるとTDDにより生み出された設計は開発者により生み出された設計そのものである。TDDの主な利点がテストカバレッジとアプリケーションの信頼性であるのに対し、疎結合、分離、そして隔離のような原則が良い設計を生み出す。
Rate this Article
- Editor Review
- Chief Editor Action