TDD: その概要、テスト原則、方法論

TDDとは？

Test-Driven Developmentは、自動化されたテストがプロダクションコードの記述を決定するソフトウェア開発手法です。コードを書いてからテストする従来のアプローチとは異なり、TDDは順序を逆にします：最初にテストを書き、次にそのテストをパスするコードを書きます。

TDDの創始者はKent Beckであり、1990年代後半にExtreme Programming（XP）手法の一部としてこのプラクティスを定式化しました。著書「Test-Driven Development: By Example」（2002年）で、BeckはTDDの5つの規則を記述し、それらは標準となりました：プロダクションコードの前にテストを書き、テストをパスするのに十分なコードだけを書き、各サイクルの後にリファクタリングする。

TDDの主要原則

第一の原則 — テストがインターフェースを定義する。開発者は、コンポーネントがどのように実装されるかを考える前に、どのように使用されるかを考えることを強いられます。これにより、最初からクリーンなAPIが形成されます。

設計技法としてのTDD

第二の原則 — 最小限の実装。テストが書かれたら、開発者はそれをパスするために必要なだけのプロダクションコードを書きます — 1行も多くは書きません。これにより、Martin FowlerがSpeculative Generalityと呼ぶ、時期尚早な抽象化と過剰な複雑さを防ぎます。

TDDと通常のテストの違い

TDDと後付けテストの主な違いは、順序の規律です。TDDでは、テストはコードを検証するだけでなく、その構造を導きます。Microsoft Researchの研究（Nagappan et al., 2008）によると、TDDを適用するチームは、従来のアプローチを使用するチームと比較して、欠陥密度が40～90%減少することが示されています。

Red-Green-Refactorサイクル

Red-Green-Refactorサイクルは、新しいテストごとに繰り返される3ステップのシーケンスです。Red：パスしないテストを書く。Green：テストをパスする最小限のコードを書く。Refactor：動作を変えずにコードを改善する。

Redフェーズ：失敗するテストを書く

開発者は、まだ実装されていない機能を検証するテストを書きます。この段階では、テストは失敗しなければなりません — これにより、テストが実際に何かを検証していることが確認されます。Android開発環境では、JUnit 5フレームワークが失敗したテストに赤いインジケータを表示し、これがフェーズの名前の由来となっています。

class CalculatorTest {
    fun testAddition() {
        val result = Calculator().add(2, 3)
        Assertions.assertEquals(5, result)
    }
}

Greenフェーズ：最小限の実装

この段階では、テストをパスするのに十分な最小限のプロダクションコードを書きます。冗長性はなし — 緑のインジケータに必要なものだけです。実装が定数で済むなら、定数のままにします。リファクタリングは次のステップで新しいテストが登場したときに行います。

class Calculator {
    fun add(a: Int, b: Int): Int {
        return a + b
    }
}

Refactorフェーズ：リスクのない改善

緑のテストはリファクタリングの保険です。開発者は、期待される動作からの逸脱をテストが即座に検出するという信頼のもとで、実装の書き換え、パフォーマンスの最適化、可読性の向上を行うことができます。Androidモバイル開発では、このフェーズは共通インターフェースの抽出とコード重複の削減に特に重要です。

モバイル開発におけるTDDの利点

モバイルプロジェクトにTDDを適用すると、学術研究と大手開発スタジオの実践の両方で確認された、測定可能な利点が得られます。

欠陥密度の低減

4つの産業プロジェクトに関するIBMの研究（Bhat & Nagappan, 2006）は、TDDを使用するチームが従来の方法で作業する同様のチームと比較して40%少ない欠陥を生み出すことを示しました。Google Playでのリリース後にバグを修正するコストがコード作成段階よりも著しく高いモバイル開発では、この指標は重要です。

テストによるコードのドキュメント化

TDDで書かれたテストは、APIの生きたドキュメントとして機能します。プロジェクトに参加する開発者はテストを読み、各コンポーネントの使用方法を理解できます。これは、チームの離職率が高い状況 — モバイルスタジオの典型的な課題 — で特に価値があります。

自信を持ったリファクタリング

90%を超えるコードカバレッジにより、開発者は何かを壊す恐れなくリファクタリングできます。Googleは著書「Software Engineering at Google」（2020年）で、テストカバレッジを数百万行のコードを持つプロジェクトでコードベースをクリーンに保つための重要な要素と呼んでいます。

TDDのためのツールとフレームワーク

モバイル開発におけるTDDエコシステムには、AndroidとiOSの両方のためのユニットテスト、モッキング、UIコンポーネント検証のツールが含まれます。

Android向けフレームワークの選択

KotlinのAndroidプロジェクトでは、標準スタックにJUnit 5 + MockKが含まれます。MockKは、追加設定なしでKotlinのファーストクラス機能（sealed class、コルーチン、suspend関数）をサポートするため、Mockitoよりも推奨されます。

iOS向けツール

iOS開発では、TDDはXCTestを通じて実装されます — Appleの組み込みフレームワークで、アサーション、テストクラス、Xcode ServerやGitHub ActionsによるCI/CD統合を提供します。iOSでのモッキングには、CuckooやOHHTTPStubsなどのライブラリが使用されます。

KotlinでのTDDコード例

Android向けKotlinでの実際のTDDシナリオを見てみましょう — ユーザーリポジトリのテストです。最初にテストを書き、次にそのテストをパスする実装を書きます。

ステップ1：UserRepositoryのテスト

class UserRepositoryTest {
    private val api = mockk<UserApi>()
    private val dao = mockk<UserDao>()
    private val repo = UserRepository(api, dao)

    fun `when api returns user then cache and emit`() = runTest {
        val user = User(1, "Alice")
        coEvery { api.getUser(1) } returns user
        every { dao.insert(user) } returns Unit

        val result = repo.getUser(1)

        assertEquals(user, result)
        verify { dao.insert(user) }
    }
}

ステップ2：最小限の実装

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUser(id: Int): User {
        val user = api.getUser(id)
        dao.insert(user)
        return user
    }
}

ステップ3：オフラインモードでのキャッシュのテスト

最初のテストをパスした後、2つ目のテストを追加します — ネットワークエラー時の動作を確認します。今度はテストが、APIが失敗した場合にリポジトリがキャッシュからデータを返すべきかを決定します。

fun `when api fails then return cached user`() = runTest {
    val cached = User(1, "Cached Alice")
    coEvery { api.getUser(1) } throws IOException()
    every { dao.getById(1) } returns cached

    val result = repo.getUser(1)

    assertEquals(cached, result)
}

TDD導入時のよくある間違い

TDDへの移行には、手法のすべての利点を無効にする可能性のある典型的な間違いが伴います。これらの落とし穴を理解することで、チームはより効果的にプラクティスを導入できます。

大きすぎるテスト

最初で最も一般的なアンチパターンは、1つのテストで大きすぎる機能範囲をテストすることです。テストは正確に1つのアサーションを検証する必要があります。テストが失敗した場合、開発者は追加のデバッグなしで何が壊れたかを正確に知る必要があります。

赤いフェーズの無視

2つ目の間違い — 最初からパスするテストを書くこと。テストが少なくとも1回は赤くなっていなければ、それが実際に何かを検証しているという確信はありません。ルール：自分が失敗するのを見たことのないテストを決して信頼してはいけません。

リファクタリングの省略

3つ目のよくある間違い — 緑のフェーズで止まること。リファクタリングはオプションではなく、サイクルの必須ステップです。それなしでは、コードベースは劣化し、テストはもろくなり、TDDの利点は失われます。

• 動作ではなく実装をテストする — テストが詳細に結びつき、リファクタリングのたびに壊れる
• エッジケースのテスト不足 — 空のリスト、null値、境界条件がカバーされないままになる
• テスト速度の無視 — 遅いテストはフィードバックループを遅らせ、TDDの規律を損なう