言語別エコシステムの現在地 — pytest・RSpec・JUnit・Goのtesting

テストフレームワークの多くは、Kent BeckのSUnit（Smalltalk、1998年）に端を発するxUnit系譜を祖先に持つ。だが、各言語のコミュニティはそこから異なる文化を育ててきた。標準ライブラリにテスト機構を内蔵する言語（Go、Rust）もあれば、サードパーティ製ツールが事実上の標準として君臨する言語（Java、JavaScript、Ruby）もある。本稿では主要言語のテストエコシステムを横断的に比較し、現在広く採用されている構成を整理する。

比較表 — 主要言語のテストエコシステム

言語	デファクト標準	アサーション/モック	特徴的な思想
Python	pytest（標準はunittest）	組み込みassert文をリライト、unittest.mock	fixture・parametrizeによる宣言的な柔軟性
Ruby	RSpec（標準寄りはminitest）	RSpec matcher / minitest assertion	DSLによる可読性 vs 素のRubyの単純さ
Java/Kotlin	JUnit 5（Jupiter）	AssertJ、Mockito、Spock	アノテーション+拡張モデル、JVM言語で共有
Go	標準testingパッケージ	testify（任意）	「フレームワーク不要」という小さな核の思想
Rust	組み込み#[test] / cargo test	proptest、quickcheck（任意）	言語機能としてテストを内蔵
C#/.NET	xUnit.net / NUnit / MSTest	Moq、FluentAssertions	三つ巴の共存、Microsoft公式は中立
PHP	PHPUnit	PHPUnit組み込み、Pest（新興）	JUnit直系の一強状態
Swift	XCTest → Swift Testing	XCTAssert系 → #expect/#require	マクロベースへの世代交代進行中
JS/TS	Vitest / Jest	内蔵アサーション、Testing Library	「オールインワン」文化（前記事参照）

Python — pytest主流、標準にunittest

Pythonの標準ライブラリにはunittestモジュールがある。これはSteve PurcellがJUnit（≒Smalltalk のSUnit）の設計をPythonに移植したもので、2001年リリースのPython 2.1に標準搭載された（当初の名称はPyUnit）。クラスベースでsetUp/tearDown、assertEqual等のメソッドを持つ、古典的なxUnitスタイルである。

しかし現在の事実上の標準はpytestである。Holger Krekelが開発した“py”ライブラリの一部として2000年代半ばに始まり、後に独立したプロジェクトとなった。pytestの特徴は以下の通り。

• クラス継承が不要で、素の関数と素のassert文でテストが書ける（アサーション自動書き換えにより、失敗時に詳細な差分を表示）
• fixture — setUp/tearDownを、依存注入的な仕組み（デコレータで宣言し、テスト関数の引数として受け取る）に置き換えた柔軟な前処理・後処理機構
• @pytest.mark.parametrize — 同じテストロジックを複数の入力パターンで繰り返し実行する仕組み
• 巨大なプラグインエコシステム（pytest-django、pytest-mock、pytest-asyncio、pytest-cov等）

pytestはunittest.TestCaseで書かれた既存テストもそのまま実行できるため、「標準はunittestだが実務はpytest」という二層構造が定着している。かつて存在したnose/nose2は開発が停滞し、現在は使われなくなっている。複数のPythonバージョンやパッケージ構成でテスト環境を切り替えたい場合にはtoxやnoxが併用されることも多い。

Ruby — RSpec対minitest

Ruby標準ライブラリには、Ryan Davisが開発したminitestが同梱されている。軽量・高速で、xUnitスタイルとスペック（describe/it）スタイルの両方をサポートする。

一方、Railsコミュニティで圧倒的な支持を得ているのがRSpecである。Steven Bakerが2005年に着想し公開、2007年に安定版1.0がリリースされた。describe / context / itという自然言語的なDSL、豊富なmatcher（expect(x).to eq(y)等）、モック機構を標準搭載し、Capybara（受け入れ・システムテスト）やFactoryBot（テストデータ生成）と組み合わせて使われることが多い。

両者の対立は「DSLによる表現力・可読性」対「素のRubyコードの単純さ・デバッグしやすさ」という設計思想の違いを象徴している。Ruby on Rails作者のDavid Heinemeier Hansson（DHH）は素のRubyに近いminitest系のスタイルを好むことで知られる。受け入れテスト・E2E寄りの領域では、Cucumber（Aslak Hellesøyが開発、Gherkin記法でGiven-When-Thenを書く）がRSpecと組み合わせて使われることも多い。

Java/Kotlin — JUnit 5とその周辺

JUnit 5（開発コードネームJupiter）は2017年9月に正式リリースされた。JUnit Platform（テスト実行基盤）、JUnit Jupiter（新しいプログラミング/拡張モデル）、JUnit Vintage（JUnit 3/4互換層）の3層構成に刷新され、@Test・@ParameterizedTest・@Nested等のアノテーションと、柔軟な拡張モデル（Extension Model）（JUnit 4のRule/Runnerを置き換え）を導入した。

周辺ライブラリも豊富である。

ライブラリ	役割	作者/由来
TestNG	JUnitの対抗馬、並列実行・依存順序指定に強い	Cédric Beust（2004年）
AssertJ	流暢なアサーション（assertThat(x).isEqualTo(y)）	Joel Costigliola（FEST-Assertから派生）
Mockito	デファクトのモックライブラリ（when/verify）	Szczepan Faber（2007〜08年頃）
Spock	Groovy製、given-when-then構造とデータ駆動テスト表	Peter Niederwieser（2008年）

Kotlinでは JUnit 5をそのまま使うことも多いが、Kotlinネイティブな DSLを持つKotest（旧KotlinTest）も一定の支持を得ている。JVM言語群は「標準ライブラリにテスト機構はなく、サードパーティ製が完全にデファクト化している」という点でGoやRustと対照的である。

Go — 標準ライブラリ主義とtable-driven test

Goは2009年の公開当初から標準ライブラリにtestingパッケージを内蔵している。Goの設計思想は「アサーションライブラリもモックライブラリも要らない」という明確な最小主義で、if got != want { t.Errorf(...) }という素朴な比較を書くのが標準的な作法とされる。

この思想の象徴がtable-driven test（テーブル駆動テスト）というイディオムである。テストケースを構造体のスライスとして列挙し、それを1つのループで回す。

func TestAdd(t *testing.T) {
    cases := []struct{ a, b, want int }{
        {1, 1, 2},
        {2, 3, 5},
        {-1, 1, 0},
    }
    for _, c := range cases {
        if got := Add(c.a, c.b); got != c.want {
            t.Errorf("Add(%d, %d) = %d, want %d", c.a, c.b, got, c.want)
        }
    }
}

より表現力の高いアサーションを求める開発者向けに、Mat Ryerらが開発したtestify（assert/require/mockパッケージ）がデファクトの補助ライブラリとして広く使われている。Goチーム自身の公式スタンスは今も最小主義寄りだが、実務ではtestifyの併用が一般的である。

Rust — 組み込みテストとproptest

Rustは言語機能として#[test]属性とcargo testコマンドを内蔵しており、外部フレームワークなしでユニットテストが書ける。慣習として、テスト対象コードと同じファイル内に#[cfg(test)] mod tests { ... }というテスト専用モジュールを置き、tests/ディレクトリには結合テスト（クレートの公開APIのみを外部から叩くテスト）を配置する。

プロパティベーステストを行いたい場合はproptestやquickcheckといったクレートを追加する。proptestはPythonのHypothesisに近い縮小（shrinking） 戦略を持ち、失敗を再現する最小の反例を自動的に探索する。標準テストランナーより高速な代替としてcargo nextestも普及している。

C#/.NET — xUnit.net・NUnit・MSTestの三つ巴

.NETのテストフレームワークは歴史的に3系統が併存している。

• NUnit — 最古参で、JUnit（≒SUnit）の設計を.NETに移植する形で生まれた
• xUnit.net — 2007年、NUnitの原作者であるJames NewkirkとBrad Wilson（当時ともにMicrosoft所属）が、NUnitの設計に蓄積した複雑さを見直す形で開発した後継的フレームワーク。[SetUp]/[TearDown]アノテーションの代わりにコンストラクタとIDisposableを使う設計など、随所にNUnitへの反省が反映されている
• MSTest — Microsoft純正、Visual Studioに標準同梱される

現在はいずれも広く使われており、明確な「一強」はない。モックライブラリとしてはDaniel Cazzulinoが開発したMoq（LINQ式構文で期待値を書ける）が主流の一つで、FluentAssertionsが流暢なアサーションの定番として併用される。

PHP — PHPUnitの一強

PHPUnitはSebastian Bergmannが開発し、2002年に最初のバージョン（0.1）が公開された。JUnitの設計をPHPに移植する形で生まれ、以来PHPにおける事実上唯一のメジャーなテストフレームワークとして君臨し続けている。Laravel・Symfonyなど主要フレームワークのテスト基盤としても採用されている。近年はPHPUnitの上に読みやすい構文を被せるPestが新興勢力として支持を広げている。

Swift — XCTestからSwift Testingへ

Apple公式のテストフレームワークは長らくXCTest（OCUnit/SenTestingKit系譜、Xcodeに統合）だった。XCTAssertEqualをはじめ40種類以上あるXCTAssert*系マクロで検証するスタイルである。

2024年のWWDCでAppleは新フレームワークSwift Testingを発表した。Swiftのマクロ機能を活用し、XCTAssert*の乱立を#expect / #requireの2つのマクロに整理、デフォルトで並列実行される設計を持つ。XCTestと同一ターゲット内で共存できるよう設計されており、既存プロジェクトからの段階的移行を前提としている。XCTestはUIテストやパフォーマンステストの領域で引き続き使われ続けている。

設計思想の対立軸 — 標準搭載 vs サードパーティ主導

各言語のテスト文化は大きく2つの軸で整理できる。

1. 標準ライブラリに内蔵するか（Go、Rust） — 言語仕様レベルで「小さな核＋規約」を提供し、フレームワーク選択の悩みそのものをなくす。ただし表現力は限定的で、補助ライブラリ（testify、proptest）が実務上ほぼ必須になりがちという逆説もある
2. サードパーティが事実上の標準になる（Java、Ruby、JS、PHP） — 言語コミュニティが単一の支配的なツールに収束することで「標準はないが事実上ある」状態を作る。この収束には時間がかかり、その過程で複数の有力候補が併存する時期（.NETの三つ巴、RubyのRSpec/minitest）が生まれる

Pythonはやや特殊で、「標準（unittest）」と「事実上の標準（pytest）」が併存し、pytestがunittest形式のテストも実行できることで緊張なく共存している。

まとめ

言語ごとのテスト文化の違いは、その言語コミュニティ自体の設計哲学を映す鏡でもある。Go・Rustの最小主義、Java・JVM系のアノテーション駆動、RubyのDSL表現力志向、JavaScriptのオールインワン化——いずれも根底にはKent BeckのSUnit/xUnitという共通の祖先がある。

この記事から次の記事へ

言語ごとに異なるツールを見てきたが、「どれだけの種類のテストを、どんな比率で書くべきか」という問いには、また別の系譜の議論がある。次の記事では、テストピラミッド・アイスクリームコーン・テスティングトロフィー・ハニカムという、テストの「形」をめぐる論争を辿る。