TDD再考 (6) – テスト容易性 ≠ 良いデザイン

• Test-induced design damage (DHH)
  • http://david.heinemeierhansson.com/2014/test-induced-design-damage.html

ソフトウェア開発の世界にTDDが紹介された当時、最も説得力があり、そして魅力的に響いた格言は「テスト容易性（Testability）を追求すれば、自然に良いプログラムをデザイン出来る」というものだった。あるモジュールをユニットテストするためには、そのモジュールをシステムの他の部分から切り離して、独立して動作させる必要がある。ということは、テストしやすいモジュールは必然的に良いモジュール設計の指標である「低結合度（low coupling）」を実現することになる。

しかし、テスト容易性は必ずしも良いデザインに結びつくわけではないと、DHH氏は言う。テストをしやすくするために、過剰な「間接層（indirection）」が導入されることによって、コードの簡潔さが失われてしまうと。

過剰な間接層の例として紹介されているのが、Hexagonal architecture というデザインパターンで、アプリケーションのコアとなるドメインモデルと外部のインタフェースを明確に分離するためのテクニックである。階層化アーキテクチャの一種と言っても良い。ドメインモデルを「ポート」と呼ばれるAPI的な層（「ポート」という語はネットワークのプロトコル・ポートや電子機器の接続を行うポートを意識している）で取り囲み、さらにその外側に「アダプタ」と呼ばれる、様々な外部システムとのやり取りをポートに適合するよう変換するためのレイヤーを配置する。

上図のシステムでは、administration, trigger data, notifications, database という４つのポートがあり、それぞれのポートに外部システムあるいはインタフェースごとのアダプタがある。

さらに今回の記事で紹介されているのは、Ruby on Rails の Controller や Active Record といったパーツを他のレイヤーに依存させずにユニットテストするためにこの Hexagonal architecture を導入するという例で、これは完全にやり過ぎであると、DHH氏は批判しているわけである。

それぞれのレイヤーを単独でテスト出来るようにするため、Controller からは直接 Active Record にアクセスさせずに Repositoryパターンを経由するようにし、Controller内のロジックは Commandパターンとして切り出す。つまり、ロジックを Rails に依存しないモジュールに配置して、それらを Rails から切り離して高速にテストできるようにするためのテクニックである。

DHH氏は、Hexagonal architecture自体を非難しているわけではなく、多種多様な外部システムに対応しなければならないシステムで役に立つ可能性については認めている。問題にしているのは、ただ「ユニットテストをやりやすくするため」だけの目的でこの複雑な構造を導入することについてである。つまり、間接層を導入してモジュールの置換可能性を高めるのは、機能的な要求があれば合理的な選択となるが、ただユニットテストのためだけにこれを導入するのは、犠牲にされたプロダクトコードの簡潔さとその見返りの釣り合いが取れないのではないかという指摘だ。

そもそもControllerの責務は、ユーザーからのリクエストとモデルからのレスポンスを統合することなのだから、ユニットテストではなく結合テスト（Integration test）で対応するべきだ、というのもなかなか説得力がある。そのように考えると、システムの中でユニットテストの対象となる部分はかなり限定されることになりそうだ（ユニットテストの定義をどう捉えるかによるが）。ドメインモデルのテストについても、データベースから切り離してテストしようとするのは時代遅れであると切り捨てている。これは筆者も同意する部分で、モデルにおいてはデータベースとのやり取りがむしろ一番重要なところであり、昨今のORMではインメモリデータベースを利用して簡単かつ比較的高速に結合テストが実施出来るため、これをやらない理由はほとんど無いように思える。

さて、TDD陣営の人たちはこの過剰な間接層問題に無頓着だったのだろうか？ 過去の資料を当たる限りそんなことはなさそうだ。Martin Fowler氏による有名な書籍『リファクタリング』の中に、Kent Beck氏による「間接層とリファクタリング」というコラムがある。

• Amazon.co.jp： リファクタリング―プログラムの体質改善テクニック
  • http://www.amazon.co.jp/dp/4894712288/

「コンピュータサイエンスは、間接層（indirection）を設けることであらゆる問題が解決できるという信念に基づいた学問である。― Dennis DeBruler」

TDDに欠かせないプラクティスであるリファクタリングは、つまるところプログラムに間接的な部分を加えるということである。この間接層というものの重要性を強調しつつも、

しかし、間接層はもろ刃の剣であることに注意しなければなりません。１つのものを２つに分割するということは、それだけ管理しなければならない部分が増えるということなのです。また、オブジェクトが、他のオブジェクトに委譲を行って、その先もさらに委譲を繰り返すような場合、プログラムが読みにくくなるのも事実です。つまり間接層は、最小限に絞り込むべきなのです。

⇒ TDD再考 (7) – テストはどこまで書けば良いのか？

TDD再考 – これまでのコンセプトマップ