xUnit のテストパターン

junit.org にアクセスすると、私の引用が表示されます。「ソフトウェア開発の分野で、これほど多くの開発者がごくわずかなコードに感謝していることはありません。」JUnit は、それこそ適格なプログラマーであれば週末にでも作成できる取るに足らないものとして批判されてきました。これは事実ですが、本質を見失っています。JUnit が重要な理由、そしてチャーチル風のボカシを認められる理由は、この小さなツールの存在が多くのプログラマーにとって根本的な変化に不可欠だったからです。テストがプログラミングの前提であり、中心的な部分に移行した変化です。以前から提唱されていましたが、JUnit は何よりもそれを実現しました。

もちろん、JUnit だけではありません。JUnit のポートは、多数のプログラミング言語向けに作成されています。xUnit ツールと呼ばれることが多い、この緩やかなツールのファミリーは、Java のルーツを大きく超えて広がっています。（そしてもちろん、ルーツは実際には Java にはなく、ケント・ベックがこのコードを数年前の Smalltalk に書いたのです。）

xUnit ツール、そしてさらに重要なのはその哲学は、プログラミングチームに大きなチャンスをもたらします。チームがはるかに少ないリスクでコードベースに劇的な変更を加えることができる、強力な回帰テストスイートを作成するチャンスです。テスト駆動開発で設計プロセスを再検討する機会です。

しかし、これらの機会には、新しい問題と新しい技術が伴います。他のツールと同様に、xUnit ファミリーは適切に使用することも、不適切に使用することもできます。思慮深い人々は、xUnit を使用してテストとデータを効果的に整理する方法をさまざまな方法で考え出しています。オブジェクトの初期の頃と同様に、ツールを本当に使用するための知識の多くは、熟練したユーザーの頭の中に隠されています。この隠れた知識がなければ、本当に完全な成果を得ることはできません。

オブジェクト指向コミュニティの人々がオブジェクトについてこの問題に気づき、回答の策定を開始したのは、ほぼ 20 年前です。その答えは、隠れた知識をパターンの形式で説明することでした。この作業の先駆者の一人がジェラルド・メザロスでした。私が初めてパターンを探求し始めたとき、メザロスは私が学んだリーダーの一人でした。パターンの世界で多くの人のように、メザロスもエクストリームプログラミングを早期に採用しており、そのため初期の頃から xUnit ツールを使用して作業していました。したがって、専門知識をパターン形式でキャプチャするタスクを引き受けたのは、極めて論理的でした。

このプロジェクトについて初めて聞いたときから、私はわくわくしていました（私はこの本をボブ・マーティンから強奪するためにコマンドー部隊を送り込みました。自分のシリーズでこの本を取り上げたかったのです）。優れたパターンに関する本のように、この本は業界の新人に知識を提供し、同じように重要なこととして、経験豊富な実践者が同僚に知識を引き継ぐための語彙や基礎を提供します。多くの人にとって、有名な Gang of Four の本はオブジェクト指向設計の隠れた宝石を見つけましたが、この本は xUnit に対して同じことをしています。