Pythonによるテスト駆動開発, 3rd Edition

第24章 「マイリスト」の完成 ：アウトサイドインTDD

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、アウトサイドインTDDと呼ばれるテクニックについて話したい。 これは、これまでずっとやってきたこととほぼ同じだ。 機能テストを先に書き、その後で単体テストを書くという 我々の「二重ループ」TDDプロセスは、 すでにアウトサイドインの実践だ。 システムを外側から設計し、コードを層状に構築する。 ここでそれを明示的にし、関連する一般的な問題点について話す。

代替案：内側から外側へ

「アウトサイドイン」の代替案として「インサイドアウト」という手法がある。 これはTDDに出会う前の多くの人が直感的に取るアプローチだ。設計を思いついた後、自然さとして、最も内側で低レベルの構成要素から実装を始めることがある。

例えば、現在の課題である保存済みリスト一覧ページ「マイリスト」の提供において、モデル層から着手したくなる誘惑がある：List モデルオブジェクトに「owner」属性を追加すべきだと考えるだろう。この種の属性は「明らかに」必要になると推論するからだ。 それが整ったら、ビューやテンプレートといった周辺レイヤーのコードを修正し、 この新属性を利用できるようにする。 最後に、新しいビューを指すURLルーティングを追加する。

この方法が心地よいのは、まだ実装されていないものに依存するコードを 一切扱わなくて済むからだ。 内部の各作業は、次の層を構築するための 確固たる基盤となる。

しかし、このように内側から外側へ向かって作業することには弱点もある。

なぜ「アウトサイドイン」を好むのか？

内側から外側へのTDDで最も明らかな問題は、 TDDのワークフローから逸脱せざるを得ない点だ。 機能テストが最初に失敗するのはURLルーティングが未実装だからかもしれないが、 それを無視して データベースモデルオブジェクトに属性を追加する作業から始めてしまう。

頭の中では、 データベースモデルのような内部レイヤーの望ましい動作について考えがあるかもしれない。 そして、その考えは往々にしてかなり良いものになる——しかし実際には、それらは本当に必要なものについての単なる推測に過ぎない。 なぜなら、それらを利用する外側のレイヤーをまだ構築していないからだ。

起こりうる問題の一つは、実際に必要以上に一般性があり 高性能な内部構成要素を構築してしまうことだ。これは時間の無駄であり、プロジェクトの複雑さを増す要因となる。 もう一つのよくある問題は、内部構成要素をその内部設計には便利なAPIで作成するものの、後になって外層が呼び出したい操作には不適切だと判明することだ。さらに悪いことに、後になって気づくかもしれないが、外層が解決を必要とする問題を実際には解決していない内部構成要素を作り上げてしまうこともある。

対照的に、アウトサイドインで作業すれば、各層から見て 下位層に求める最も便利なAPIを想像できる。 実際に動いている様子を見てみよう。

「マイリスト」の機能テスト

以下の機能テストを進めるにあたり、 最も外側を向いた層（プレゼンテーション層）から始め、 ビュー関数（または「コントローラー」）を経て、 最後に最も内側の層（この場合はモデルコード）へと進む。 図24-1を参照。

図 24-1. アプリケーションのレイヤー

図を描いているついでに、想像していることをスケッチしてみるのはどうだろう？ ...