ボブおじさんの名著『アジャイルソフトウェアの奥義』を読み返しながら感想などをつらつらと書き連ねるシリーズ2回目。

第3章 プラニング

この章では、XP（エクストリームプラニング）のプラクティスのひとつ「計画ゲーム」について説明されている。特筆すべき点はないので割愛。

第4章 テスティング

テストコードを書くこと、テスト駆動で開発を行うことの重要さが説かれている。

つまり、テストを最初に書くという行為は、設計上の判断をふるいにかける行為でもあるのだ。

『アジャイルソフトウェア開発の奥義』（第4章, p. 35）

プログラムが解決しようとしている領域において、どの概念が他の概念より重要なのか、重要なエンティティやビジネスルールとしてどれを中心に据えるべきなのかといった設計判断の良し悪しが、テストコードを先に書くことによって明確になるという意味だろう。

どんなプログラムにもその利用者（クライアント）が存在し、そのクライアントのニーズを満たすために存在する。クライアント側がプログラムをどのように利用したいのか、を先に書くことで過不足のないちょうどよい設計になるというのがテスト駆動開発の、とくにアウトサイドインのアプローチのメリットなのだ。

また、テストコードを先に書くことで、対象が自然とテストしやすい形、つまりモジュールが周囲から分離された構造に行き着くとボブおじさんは言う。

本書の大半は、プログラムの依存関係をうまく管理するための設計原則について書かれている。それらの原則はクラスやパッケージを分離するときのガイドラインやテクニックとして使える。こういった原則が最も役に立つのは、ユニットテストの記述方針を決めるときだろう。ユニットテストこそが、分離を推進しその方向性を決定付けるからだ。

（第4章, p. 38）

次に、受け入れテストについて。

受け入れテストはUIを通さずに行い、ビジネスルールを検証できる必要があると述べられている。また、必ずそれを自動化すべきであると。
E2Eで網羅的な受け入れテスト記述することはコストに見合わないので避けた方がよいというのは最近でもよく聞く話だ。

さらに、受け入れテストの自動化にあたっては、顧客にも理解可能な形式で書かれたスクリプトを入力として受け取りそれを解釈し、アプリケーションに対する命令として送ることが提案されている。
この手法はまさにBDD（振舞い駆動開発）であるし、「顧客にも理解可能な形式で書かれたスクリプト」とはDSL（ドメイン固有言語）であろう。

テスト用の入力も実際のアプリケーション画面からの入力も受け付けることができ、ビジネスロジックを起動するためには、アーキテクチャが適切に分離されていなければならない。ゆえに受け入れテストを最初に書いて自動化するという行為がアーキテクチャを良い方向に導いていく。ボブおじさんはこれを「自然に導かれるアーキテクチャ」と呼ぶ。

そしてこのアーキテクチャこそ、まさにクリーンアーキテクチャということになるのだろう。

いや〜、改めて名著だなぁ。

つづく。