xUnitの誕生 — SUnitからJUnitへ、伝説の機内ペアプロ

理論はあった。 だが道具がなかった

前史で見たように、 1970年代末までにソフトウェアテストは理論的には体系化されていた。 Myers はテストの目的と技法を一冊にまとめ、 Dijkstra はその限界を明らかにし、 Boehm は検証と妥当性確認を区別した。 しかし実務では、 単体テスト(unit test)を書き、 実行し、 結果を確認するための共通の道具立ては存在しなかった。

多くの現場では、 テストは print 文で出力を目視確認する、 あるいは使い捨てのスクリプトを書いてその場限りで確認するといった、 属人的で再現性の低い作業だった。 同じ確認を繰り返すたびに手間がかかり、 「テストを何度も自動で回す」という発想自体が一般的ではなかった。

この状況を一変させたのが、 Kent Beck が Smalltalk 向けに作った小さなテストフレームワーク SUnit と、 それを Java に移植した JUnit である。 本記事では、 この二つのフレームワークの誕生の経緯と、 そこで確立された「xUnit アーキテクチャ」が単体テストのあり方をどう変えたかを見ていく。

Kent BeckとSUnit — Smalltalkにおける単体テストの実験

Kent Beck は1980年代末、 Smalltalk 環境で自らのプログラミングを支援するための小さなテストフレームワークを書いた。 これが後に SUnit と呼ばれるものである。

Beck はこの設計を1994年、 雑誌 The Smalltalk Report に掲載された論文「Simple Smalltalk Testing: With Patterns」の中でパターン集として文書化した。 この論文は、 単に動くコードを示すだけでなく、 「なぜこの構造にするのか」という設計判断をパターンという形式で言語化した点で、 後の xUnit 系フレームワークの設計思想に大きな影響を与えている。 なお SUnit の正確な誕生年については、 公開された論文自体は1994年発表だが、 Beck 自身が後年「1994年に書いたと思う」と述べる一方、 初期の着想はさらに遡るとの記述も見られ、 資料によって多少の揺れがある。

SUnit の設計は驚くほど単純である。

• テストは TestCase のサブクラスとして書く
• 一つのテストメソッドが一つの検証項目に対応する
• setUp で各テストの前提条件(fixture)を用意する
• assert: のようなメッセージで期待値と実際の値を比較する
• 複数のテストケースを TestSuite にまとめて一括実行する

重要なのは、 Beck がこれを「フレームワーク」として作ったことだ。 つまり、 テストの実行・結果集計・失敗の報告といった繰り返し作業を、 テストを書く人間ではなくフレームワーク側の責務にした。 この発想は、 後に Beck が提唱するエクストリーム・プログラミング(Extreme Programming, XP)およびテスト駆動開発(Test-Driven Development, TDD)の実践基盤となっていく。 TDD の詳しい経緯は、 のちの第4話で扱う。

伝説の飛行機 — JUnitはこうして生まれた

1997年、 Kent Beck は『デザインパターン』(Design Patterns, 1994)の共著者としても知られるソフトウェア工学者 Erich Gamma とともに、 チューリッヒからアトランタで開催される OOPSLA ’97 カンファレンスへ向かうフライトに乗り合わせた。

長時間のフライトの間、 二人は SUnit のアイデアを Java に移植する作業を、 ペアプログラミング(pair programming)で、 しかもテストファースト(test-first)で進めたという逸話が広く伝えられている。 この機上のセッションで書かれたコードが、 JUnit の最初のバージョンの原型となった。

JUnit はその後まもなく公開され、 瞬く間に Java コミュニティの標準的な単体テストツールとなった。 Beck がすでに Smalltalk コミュニティで確立していた xUnit 的な設計思想と、 Gamma のオブジェクト指向設計に関する深い知見が組み合わさったことで、 JUnit は単なる「SUnit の移植」を超えて、 以後のあらゆる言語のテストフレームワークが手本とする完成度の高い設計になった。

この逸話がテスト史においてしばしば語り草になるのは、 単なる美談としてだけではない。 「テストフレームワーク自体をテスト駆動で作る」という、 後に『Test-Driven Development: By Example』(2002)で Beck が体系的に示すことになる実践スタイルが、 JUnit 誕生の場面ですでに体現されていたという点で象徴的だからである。

xUnitアーキテクチャの構成要素

SUnit と JUnit が確立し、 以後のほぼすべての単体テストフレームワークが踏襲することになった基本構造を「xUnit アーキテクチャ」と呼ぶ。 その構成要素は次の通りである。

構成要素	役割
TestCase	一つの検証項目(テストケース)を表すクラスまたは関数。 通常、 独立して実行可能な最小単位
TestSuite	複数の TestCase をまとめて一括実行するための入れ物
TestRunner	TestSuite を実際に実行し、 成功・失敗・エラーを収集して報告するプログラム
Assertion(表明)	「期待値と実際の値が一致するか」などを検証し、 不一致であればテストを失敗させる仕組み(assertEquals など)
Fixture(フィクスチャ)	テスト実行に必要な前提条件・環境(テスト対象オブジェクトの初期状態、 テストデータなど)
setUp / tearDown	各テストの実行前に fixture を用意し(setUp)、 実行後に後片付けをする(tearDown)ためのフック

この構造の肝は、 「テストケースごとに独立した fixture を用意し直す」という原則にある。 あるテストが別のテストの後始末不足によって失敗する、 といった相互依存を避けることで、 テストの信頼性と再現性が保たれる。 この設計判断は、 後年フレーキーテスト(flaky test、 第14話参照)を防ぐ基本原則としても重要になる。 テストの独立性という原則は、 地味に見えて、 xUnit アーキテクチャが数十年にわたって色あせない理由の一つである。

なぜフレームワーク化が単体テストを一般化・自動化させたのか

SUnit・JUnit 以前にも、 開発者たちは何らかの形で動作確認を行っていた。 しかしそれは、 次のような性質を持つ属人的な作業だった。

• テストコードの書き方に共通の型がなく、 チームやプロジェクトごとにやり方がばらばら
• 実行結果の集計・報告が手作業で、 多数のテストケースを回すコストが高い
• テストの独立性(前のテストの影響を受けないこと)が保証されておらず、 信頼性が低い
• 「テストを書く」という行為がプログラマの標準的な作業として認識されていない

xUnit アーキテクチャの登場によって、 この状況は次のように変わった。

1. 共通の型ができた — TestCase・assert・setUp という語彙を共有することで、 他人の書いたテストを読み書きするコストが劇的に下がった
2. 実行と集計が自動化された — TestRunner が全テストをまとめて実行し、 緑(全成功)か赤(失敗あり)かを一瞬で示すようになった
3. IDEやビルドツールとの統合が進んだ — JUnit は IDE(Eclipse など)やビルドツール(Ant、 Maven など)に深く統合され、 「保存するたびにテストが回る」という開発体験が一般化した
4. テストを書くコストが劇的に下がった — 定型的な構造に沿ってテストメソッドを追加するだけでよくなり、 テストを書くこと自体の心理的・時間的コストが下がった

この結果、 単体テストは一部の意識の高い開発者だけの実践から、 業界全体の当たり前の作業へと変わっていった。 これは、 シリーズ overview で触れた「手動から自動化へ」という糸が、 最初に大きく前進した瞬間である。

簡単なJUnit風コード例

xUnit アーキテクチャのイメージをつかむため、 シンプルな電卓クラスに対する JUnit 風のテストコード例を示す。 現代的な JUnit 5(Jupiter)のアノテーションスタイルで書いている。

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.BeforeEach;
import static org.junit.jupiter.api.Assertions.assertEquals;

class CalculatorTest {

    private Calculator calculator;

    @BeforeEach
    void setUp() {
        // 各テストの前に新しいインスタンスを用意する(fixture)
        calculator = new Calculator();
    }

    @Test
    void addsTwoPositiveNumbers() {
        int result = calculator.add(2, 3);
        assertEquals(5, result); // assertion
    }

    @Test
    void addsNegativeNumbers() {
        int result = calculator.add(-2, -3);
        assertEquals(-5, result);
    }
}

@BeforeEach(旧 setUp)が fixture の準備を担い、 各 @Test メソッドが独立した TestCase として実行され、 assertEquals が Assertion の役割を果たす。 この構造は1990年代の SUnit・JUnit からほとんど変わっておらず、 xUnit アーキテクチャの寿命の長さを物語っている。

JUnitのその後の進化と絶大な影響力

JUnit 自体もその後、 進化を続けている。 クラシックな TestCase 継承スタイルの JUnit 3、 2006年にアノテーション @Test ベースのスタイルを導入した JUnit 4、 そして2017年にモジュール化されたアーキテクチャへ刷新された JUnit 5(Jupiter)と、 世代を重ねてきた。

JUnit はその後、 Java コミュニティの外にも広く影響を及ぼした。 単体テストという行為が「一部の熱心な開発者だけの習慣」から「業界標準のプラクティス」へと変わっていく過程で、 JUnit はその中心的な触媒であり続けた。

• 「テストクラスに TestCase という単位を作り、 assert で検証し、 setUp/tearDown で fixture を管理する」という設計は、 ほぼそのままの形で他言語に移植されていった。 この移植の波は次の第3話で扱う
• JUnit の成功は、 「テストコードもまた保守すべき一級の成果物である」という考え方を業界に定着させた
• 「テストフレームワーク自体をテスト駆動で作る」という実践は、 のちに TDD として体系化される発想の先取りでもあった

まとめ — 語彙が世界を変えた

SUnit と JUnit の誕生は、 「テストを書くことが特別な作業ではなく、 日常的なプログラミング作業の一部になる」という転換をもたらした。 この転換の核心は、 TestCase・assertion・fixture・setUp/tearDown という共通の語彙とアーキテクチャを確立したことにある。

この設計はきわめて普遍性が高く、 次の記事で見るように、 C++・.NET・Python・Ruby・PHP など、 ほぼすべての主要言語に同じ発想のまま移植されていくことになる。 一つの機内で書かれた小さなコードが、 30年近くにわたって世界中の開発者の日常を形づくり続けている——これもまた、 テストの歴史が持つ意外性の一つである。

次の第3話では、 JUnit の設計思想がどのようにして各言語のコミュニティへ広がり、 それぞれの言語文化に合わせて変容していったかを見ていく。