テストコードが壊れやすい問題を解決！Bottleの統合テストをクリーンに保つ設計手法

統合テストは、Webアプリケーションの振る舞いを保証する上で不可欠な存在です。
しかし、Bottleのような軽量フレームワークで開発を進める際、ルーティングハンドラとデータアクセス層の密結合が原因で、わずかな実装の変更がテストコードの大規模な修正を引き起こすことは少なくありません。
なぜ、多くの統合テストはリファクタリングのたびに脆く崩壊してしまうのでしょうか。

この問題の本質は、テスト対象の「関心事の分離」が不十分なことにあります。
HTTPリクエストの受信、ビジネスロジックの実行、永続化層へのアクセスが一つの関数内で交錯する状態では、テストは必然的に実装の詳細に依存し、変更に弱い構造を生み出してしまいます。
コンピューターサイエンスの観点から見れば、これはモジュール間の結合度が高く、凝集度が低い状態、すなわち設計上の技術的負債がそのままテストコードに投影された結果です。

本記事では、Bottleアプリケーションの統合テストをクリーンに保つ具体的な設計手法を検討します。
依存性注入の原則に基づき、インメモリリポジトリによるテストダブルの活用、およびレイヤードアーキテクチャの導入を通じて、実装の変更に強いテストスイートを構築する方法を提示します。

• 関心事の分離: ハンドラ層とドメイン層を分離し、テスト対象の境界を明確に定義します
• 依存性の注入: 具体的な実装ではなく抽象に依存させ、データベースアクセスを差し替え可能にします
• アサーションの本質化: HTTPステータスコードだけでなく、境界を超えた振る舞いの検証に注力します

壊れやすいテストコードに悩まされているエンジニアの方々にとって、本稿が堅牢な統合テスト設計への一助となれば幸いです。

Bottle統合テストが壊れやすい根本原因：実装詳細への過度な依存

統合テストは、モジュール間の相互作用を検証し、システム全体の振る舞いを保証する上で極めて重要な役割を担います。
しかしながら、Bottleを用いたWebアプリケーション開発において、統合テストが変更に対して極めて脆弱になるケースは少なくありません。
なぜ、本来は安全網となるべきテストコードが、リファクタリングのたびに障害物と化してしまうのでしょうか。
その根本原因は、テスト対象が実装の詳細、特にデータ永続化の機構に過度に依存していることにあります。
コンピューターサイエンスの観点から言えば、これは情報隠蔽の原則が十分に適用されておらず、モジュール間のインターフェースが適切に抽象化されていない状態を反映しています。

ルーティングハンドラとデータ層の密結合が招くテストの脆弱性

多くのBottleアプリケーションでは、ルーティングハンドラ内で直接SQLクエリを発行したり、ORMセッションを操作したりする実装が見受けられます。
このような構造は、一見すると簡潔で理解しやすいコードに見えますが、ソフトウェア工学の観点からは極めて危険な結合を生み出しています。
ハンドラ層がデータ層の具体的な実装に依存している状態では、データベーススキーマのわずかな変更、あるいはクエリの最適化による修正が、テストコードの大規模な書き換えを強いることになります。

たとえば、以下のような実装を考えてみます。

import sqlite3
from bottle import route

@route('/api/users/<user_id>')
def get_user(user_id):
    conn = sqlite3.connect('production.db')
    cursor = conn.cursor()
    cursor.execute(
        "SELECT id, name, email FROM users WHERE id = ?", 
        (user_id,)
    )
    row = cursor.fetchone()
    conn.close()
    return {
        "id": row[0], 
        "name": row[1], 
        "email": row[2]
    }

このコードにおいて、統合テストを実行するためには実際のSQLiteデータベースファイルへアクセスする必要があります。
ファイルシステムへの依存が生じることで、テストの実行速度が低下するだけでなく、テスト環境の再現性も損なわれます。
さらに、テスト対象がデータベース接続の確立からクエリの発行、結果のマッピングまで全ての責務を担っているため、どの部分で障害が発生したのかを切り分けることも困難になります。
単一責任の原則に反するこの構造は、テストの脆弱性を本質的に内包していると言えるでしょう。

軽量フレームワーク特有の「簡潔さの罠」と結合度の上昇

Bottleのようなマイクロフレームワークは、その軽量さと最小限の学習コストにより、迅速なプロトタイピングに優れた選択肢となります。
しかし、この「簡潔さ」がしばしば設計上の無関心を招き、結果として結合度の上昇をもたらす「簡潔さの罠」に陥りやすいことも事実です。
フレームワークが提供する自由度の高さは、適切なアーキテクチャ設計なしには、ビジネスロジックとインフラストラクチャコードの混在を容認してしまいます。

以下の表は、軽量フレームワークにおける典型的な結合の問題と、それがテストに与える影響を整理したものです。

結合の種類	具体的な症状	テストへの影響
データ層への密結合	ハンドラ内で直接SQLを発行する	データベースの準備が必須になりテストが重くなる
フレームワークへの密結合	リクエストオブジェクトをビジネスロジックに渡す	テスト時にHTTPコンテキストの模擬が必要になる
設定値への密結合	データベースパスをコード内にハードコードする	テスト環境と本番環境の切り替えが困難になる

このように、結合度が上昇する要因は複数存在しますが、いずれも共通して「抽象への依存」ではなく「具体への依存」を生み出している点に着目すべきです。
オブジェクト指向設計の基本原則である依存関係逆転の原則を無視した構造は、テストコードのメンテナンスコストを指数的に増大させ、長期的な開発速度の低下を招きます。
軽量フレームワークを選んだからこそ、開発者自身が意識的に境界を設け、関心事を分離する責務を負う必要があるということです。

コンピュータサイエンスの視点で読み解く結合度と凝集度の問題

ソフトウェアの設計品質を議論する際、結合度と凝集度は避けて通れない基本概念です。
これらは1970年代にStevensらによって構造化設計の文脈で体系化され、それ以来、モジュール性を測る重要な指標として広く認識されています。
結合度はモジュール間の相互依存の強さを示し、凝集度は一つのモジュール内における要素間の関連性の強さを示します。
コンピューターサイエンスの観点から見れば、優れたソフトウェアアーキテクチャとは、低結合かつ高凝集の状態を志向するものです。
なぜこの二つの指標が、統合テストの健全性と深く関わっているのでしょうか。

高結合・低凝集が統合テストのメンテナンスコストを増大させるメカニズム

高結合の状態では、あるモジュールの変更が他のモジュールに連鎖的に伝播しやすくなります。
統合テストは複数のモジュールを協調させて検証するテストであるため、この変更の連鎖はテストコードの脆弱性として直接的に現れます。
たとえば、データベース接続の確立方法を変更しただけで、HTTPハンドラのテストが失敗するような構造は、モジュール間の境界が明確でないことを物語っています。
これは、テスト対象が本来関心を持つべきでない実装の詳細に過度に依存している証左です。

一方、低凝集は一つのモジュール内に複数の関心事が混在している状態を指します。
HTTPリクエストの解析、ビジネスルールの適用、データの永続化が一つの関数内で実行されている場合、そのモジュールは複数の責務を負っていることになります。
このような状態では、テストケースを構築する際にどの振る舞いを検証すべきかが不明瞭になり、テストコード自体も複雑化します。
結果として、リファクタリング時にテストを修正するコストが増大し、開発者はテストの存在を負担に感じるようになります。

以下の表は、結合度と凝集度の状態がテスト特性に与える影響を整理したものです。

指標	高結合・低凝集の状態	低結合・高凝集の状態
変更の影響範囲	関係するモジュール全体に伝播しやすい	モジュール内部に局所化される
テストの独立性	外部リソースや他モジュールへの依存が高い	テストダブルによる代替が容易
保守性	修正時の副作用予測が困難	境界が明確で予測可能性が高い

この表からも読み取れるように、高結合・低凝集の構造は、テストの実行可能性と保守性の両方を著しく低下させる要因となります。

変更に強いモジュール設計のためのソフトウェア工学上の指針

では、どのようにして低結合・高凝集を実現し、変更に強いモジュール設計を行えばよいのでしょうか。
まず第一に、情報隠蔽の原情報隠蔽**の原則を徹底することが挙げられます。
Parnasが提唱したこの原則は、モジュールの内部実装の詳細を隠蔽し、公開インターフェースのみを他のモジュールに見せることを要求します。
これにより、実装の変更がモジュールの外部に影響を及ぼす範囲を最小限に抑えることができます。

次に、単一責任の原則に従い、一つのモジュールは一つの責務のみを担うように設計します。
そして、依存関係逆転の原則を適用し、上位のモジュールが下位のモジュールの具体的な実装に依存するのではなく、両方が抽象に依存するようにします。
以下のコードは、抽象に依存するリポジトリパターンの基本的な構造を示しています。

from abc import ABC, abstractmethod
from dataclasses import dataclass

@dataclass
class User:
    id: int
    name: str
    email: str

class UserRepository(ABC):
    @abstractmethod
    def get_by_id(self, user_id: int) -> User | None:
        pass

class InMemoryUserRepository(UserRepository):
    def __init__(self):
        self._users = {}

    def get_by_id(self, user_id: int) -> User | None:
        return self._users.get(user_id)

この設計により、ハンドラ層はUserRepositoryという抽象に対してのみ依存し、テスト時にはInMemoryUserRepositoryのような軽量な実装に差し替えることが可能になります。
コンピューターサイエンスの言葉で表現すれば、これは実装の結合をインターフェースの結合に置き換えることであり、システムの柔軟性とテスト容易性を根本から向上させる手法です。
設計の指針を意識することで、統合テストは実装の詳細ではなく、モジュール間の契約に焦点を当てた堅牢な検証装置へと生まれ変わります。

依存性注入で解決するBottleアプリケーションの関心事分離

前節までに、結合度と凝集度の観点から統合テストが脆くなる構造的な原因を論じてきました。
では、Bottleのようなマイクロフレームワークを用いた場合に、どのようにして関心事を分離し、テスト容易性を確保すればよいのでしょうか。
答えは、依存性注入の原則をアプリケーション設計の中核に据えることにあります。
依存性注入とは、オブジェクトの生成やライフサイクルの管理を利用する側ではなく、外部の機構に委譲するデザインパターンです。
これにより、実行時の振る舞いを差し替えることが可能になり、統合テストにおいても本番環境と異なる実装を安全に組み込むことができます。

抽象への依存を原則としたリポジトリパターンの導入

具体的な実装に依存したコードは、テスト時にその実装をそのまま引きずることを強います。
これを防ぐためには、データアクセスの責務を抽象化したリポジトリパターンの導入が有効です。
リポジトリは、ドメインオブジェクトの永続化と再構成を担当する境界として機能し、アプリケーションの他の部分からデータストアの詳細を隠蔽します。
Bottleのハンドラがリポジトリのインターフェースに対してのみ依存するように設計すれば、本番環境ではデータベースを用いた実装を、統合テストではインメモリ実装を注入することが可能になります。

この設計の本質は、依存関係逆転の原則の適用にあります。
上位のモジュールであるハンドラが、下位のモジュールである具体的なデータアクセス実装に依存するのではなく、両者が抽象に依存することで、変更の影響を局所化します。
コンピューターサイエンスの観点から言えば、これは実装の結合を契約による結合へと昇華させる作業です。

Bottleのプラグイン機構とDIコンテナの代替実装戦略

BottleはフルスタックのDIコンテナを内包していませんが、Bottle.pluginの機構を活用することで、依存性注入と同等の効果を簡潔に実現できます。
プラグインを用いれば、各ルートのコールバックに対して引数を解決するロジックを登録でき、これをDIの仕組みとして転用することが可能です。

以下は、リポジトリをハンドラに注入するための簡易的なプラグイン実装の例です。

from bottle import Bottle, request, response
import inspect

app = Bottle()

class RepositoryPlugin:
    name = 'repository_plugin'
    api = 2

    def __init__(self, repository_impl):
        self.repository = repository_impl

    def apply(self, callback, route):
        args = inspect.signature(route.callback).parameters

        def wrapper(*a, **ka):
            if 'user_repo' in args:
                ka['user_repo'] = self.repository
            return callback(*a, **ka)
        return wrapper

このプラグインをアプリケーションに適用することで、ハンドラは以下のように宣言的に依存性を受け取ることができます。

@app.get('/api/users/<user_id>')
def get_user(user_id, user_repo):
    user = user_repo.get_by_id(int(user_id))
    if not user:
        response.status = 404
        return {"error": "Not found"}
    return {
        "id": user.id,
        "name": user.name,
        "email": user.email
    }

テスト時にはこのプラグインにインメモリのリポジトリ実装を渡し、本番環境ではデータベースを用いた実装を渡すことで、同一のハンドラ実装をまったく変更することなく異なる永続化戦略の下で検証できます。
フレームワークの軽量さを活かしつつ、明確な境界を設けることで、統合テストは実装の詳細ではなく振る舞いの契約に焦点を当てた堅牢な検証装置へと変貌します。

インメモリリポジトリを活用したテストダブルの実装と使い分け

依存性注入の仕組みを整備した後、統合テストを実際に運用するためには、本番の永続化機構に代わる軽量な実装、すなわちテストダブルを準備する必要があります。
テストダブルとは、テスト実行時に本物のコンポーネントの代わりに用いられるオブジェクトの総称です。
しかし、ダブルと一言で表しても、その種類は複数存在し、それぞれ異なる目的と特性を持ちます。
統合テストの文脈において、なぜインメモリリポジトリが特に有力な選択肢となるのでしょうか。

FakeオブジェクトとMockの違いと統合テストにおける選択基準

テストダブルの分類において、特に混同されやすいのがFakeとMockです。
両者は一見似た役割を担うように見えますが、設計思想と適用場面に明確な差異があります。
Mockは、あるオブジェクトが特定のメソッドを呼び出したか、その際に正しい引数を渡したかを検証するために用いられる、振る舞いの検証に特化したオブジェクトです。
一方、Fakeは、本物の実装を模倣した軽量な代替実装であり、実際に状態を保持し、本物と同じように振る舞います。

統合テストにおいては、モジュール間の協調動作の結果を検証することが目的です。
そのため、個別のメソッド呼び出しの検証に注力するMockよりも、実際の永続化操作を模倣するFakeの方が本質的に適しています。
Fakeを用いれば、テスト対象の振る舞いがデータストアを通じてどのように実現されるかを、外部のプロセスやファイルシステムに依存することなく検証できます。

以下の表は、FakeとMockの主な違いと統合テストにおける選択基準を整理したものです。

観点	Fake	Mock
主な目的	状態を持つ軽量な代替実装として動作する	特定のメソッド呼び出しの検証を行う
内部状態	テスト実行中に実際に状態を保持する	通常、呼び出し履歴の記録に留まる
統合テストでの適性	高い。モジュール間のデータの流れを再現できる	低め。実装の詳細に過度に結合しやすい
保守性	変更に強く、リファクタリングの影響を受けにくい	インターフェース変更時に破壊されやすい

この表からも明らかなように、統合テストにおいてはFakeを優先的に採用し、実装の詳細ではなく最終的な状態の変化に焦点を当てることが、長期的な保守性を担保する上で合理的な判断です。

SQLiteインメモリモードを用いた高速で再現性のあるテスト環境構築

Fakeオブジェクトは極めて有用ですが、SQLのような複雑なクエリやデータベース固有の機能を利用している場合、Fakeで完全にその振る舞いを再現することは困難な場合があります。
このような場面では、SQLiteのインメモリモードを活用することで、本物のRDBMSに極めて近い環境を、ファイルシステムへの依存なしに構築できます。
インメモリデータベースは、テストプロセス内に完全に閉じた状態で動作するため、テスト間の独立性が厳密に保たれ、再現性のある検証が可能になります。

SQLiteのインメモリ接続は、接続文字列の指定一つで実現できます。

import sqlite3

def create_test_connection():
    return sqlite3.connect(":memory:")

さらに、テストごとにデータベーススキーマを初期化し、テスト終了後に接続を破棄することで、完全にクリーンな状態を保つことができます。
以下は、リポジトリの実装に対してインメモリSQLiteを注入する構成例です。

class SQLiteUserRepository(UserRepository):
    def __init__(self, connection):
        self.conn = connection
        self._ensure_table()

    def _ensure_table(self):
        self.conn.execute(
            "CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT, email TEXT)"
        )
        self.conn.commit()

    def add(self, user: User) -> None:
        self.conn.execute(
            "INSERT INTO users (id, name, email) VALUES (?, ?, ?)",
            (user.id, user.name, user.email)
        )
        self.conn.commit()

    def get_by_id(self, user_id: int) -> User | None:
        cursor = self.conn.execute(
            "SELECT id, name, email FROM users WHERE id = ?", 
            (user_id,)
        )
        row = cursor.fetchone()
        if row:
            return User(id=row[0], name=row[1], email=row[2])
        return None

このように、FakeとSQLiteインメモリモードを使い分けることで、単純なCRUD操作を持つドメインでは軽量なFakeを、複雑なクエリが絡む場面ではSQLiteを用いるという、段階的で実用的な戦略を構築できます。
統合テストの速度と信頼性の両立という課題に対し、テストダブルの特性を理解した上で最適な選択を行うことこそが、堅牢なテストスイートの基盤となります。

レイヤードアーキテクチャによるハンドラ層とドメイン層の分離設計

依存性注入とテストダブルの仕組みを整備しても、ハンドラ内にビジネスロジックが直接記述されていれば、関心事の分離は依然として不完全です。
HTTPリクエストの受信、入力の検証、ビジネスルールの適用、データの永続化、レスポンスの生成が一つの関数内で交錯する状態は、いわゆる「スマートUI」のアンチパターンに他なりません。
コンピューターサイエンスの観点から見れば、これは異なる抽象度の処理が同一のモジュール内に混在し、凝集度を著しく低下させている状態です。
レイヤードアーキテクチャは、この問題を解決するための古典的かつ実績のあるアプローチです。
プレゼンテーション層、アプリケーション層、ドメイン層、インフラストラクチャ層という明確な階層を定義することで、各層の責務を限定し、上位層が下位層の実装詳細に依存しない構造を実現します。

アプリケーション層の責務を限定したクリーンなハンドラ実装

Bottleのハンドラは、あくまでHTTPという外部インターフェースとアプリケーション内部の橋渡しを担う存在であるべきです。
ハンドラの責務は、リクエストボディの解析、必要に応じた入力検証、ユースケース層への処理の委譲、そして結果をHTTPレスポンスにマッピングする操作に限定されます。
ビジネスルールの判断やデータアクセスの詳細がハンドラに漏れ込んでいる状態は、テスト容易性を著しく損ないます。

以下は、責務を明確に限定したハンドラの実装例です。

from bottle import request, response

@app.post('/api/users')
def create_user(user_repo):
    payload = request.json

    if not payload or 'name' not in payload:
        response.status = 400
        return {"error": "Name is required"}

    use_case = CreateUserUseCase(user_repo)
    result = use_case.execute(payload['name'], payload.get('email', ''))

    response.status = 201
    return {
        "id": result.id,
        "name": result.name,
        "email": result.email
    }

この実装において、ハンドラはHTTPの文脈、すなわちステータスコードやJSONのシリアライゼーションにのみ関与しています。
ユーザー名の重複チェックやメールアドレスの正規化といったビジネスロジックは、ハンドラの外に追い出されています。
このように責務を限定することで、HTTPに関する結合のみを持ち、ドメイン知識への依存を排したクリーンなハンドラを実現できます。

ユースケース層の導入でビジネスロジックをHTTPから独立させる方法

ユースケース層は、アプリケーション層とドメイン層の間に位置し、特定のユーザーの操作に対する一連のビジネスロジックをカプセル化します。
この層を導入することで、ビジネスロジックはHTTPリクエストの構造から完全に解放され、純粋なPythonのオブジェクトとして検証可能になります。
コンピューターサイエンスの文脈では、これは関心事の分離と抽象化の深化であり、システムの変更耐性を根本から高める設計判断です。

以下は、ユーザー作成の責務を担うユースケースの実装例です。

import uuid
from dataclasses import dataclass

@dataclass
class CreateUserResult:
    id: str
    name: str
    email: str

class CreateUserUseCase:
    def __init__(self, user_repository):
        self.user_repository = user_repository

    def execute(self, name: str, email: str) -> CreateUserResult:
        if len(name) < 3:
            raise ValueError("Username must be at least 3 characters long")

        user_id = str(uuid.uuid4())
        user = User(id=user_id, name=name, email=email)

        self.user_repository.add(user)

        return CreateUserResult(
            id=user.id,
            name=user.name,
            email=user.email
        )

このユースケースは、HTTPリクエストの存在を一切知りません。
受け取るのはプリミティブな値とリポジトリの抽象であり、返すのはドメインの結果オブジェクトです。
これにより、ユースケースの統合テストはHTTPサーバーを立ち上げることなく、インメモリリポジトリを注入するだけで実行可能になります。
レイヤードアーキテクチャの導入は、一見すると過剰な構造に見えるかもしれませんが、長期的な保守とテストの健全性を担保する上で、極めて合理的な投資です。

実装例：Bottleでクリーンな統合テストを構築する具体的なステップ

前節までに論じた設計原則を、いよいよ実際のコードに落とし込みます。
理論的な理解は重要ですが、最終的にはテストコードが実際に動作し、リファクタリングのたびに崩壊しないことが何よりの証左です。
では、Bottleアプリケーションに対してどのようにしてクリーンな統合テストを構築すればよいのでしょうか。
ここでは、タスク管理のような具体的なユースケースを題材に、サービスクラスの設計からpytestによる検証までの流れを具体的に示します。

テスト対象のサービスクラス設計とインターフェース定義

まず、テスト対象となるビジネスロジックをサービスクラスとして分離し、それが依存するリポジトリのインターフェースを明確に定義します。
これにより、テスト時に具体的な永続化機構を差し替えるための接合点が生まれます。

from abc import ABC, abstractmethod
from dataclasses import dataclass

@dataclass
class Task:
    task_id: str
    title: str
    completed: bool = False

class TaskRepository(ABC):
    @abstractmethod
    def save(self, task: Task) -> None:
        pass

    @abstractmethod
    def get_by_id(self, task_id: str) -> Task | None:
        pass

class TaskService:
    def __init__(self, repository: TaskRepository):
        self.repository = repository

    def complete_task(self, task_id: str) -> Task:
        task = self.repository.get_by_id(task_id)
        if task is None:
            raise ValueError("Task not found")
        task.completed = True
        self.repository.save(task)
        return task

この設計において、TaskServiceは永続化の詳細を一切知りません。
それがインメモリ実装であろうと、SQLiteであろうと、サービスクラスの振る舞いは変わりません。
これこそが、抽象への依存を徹底した状態です。

pytestフィクスチャを用いた依存性の注入とセットアップの共通化

次に、pytestのフィクスチャを活用して、テスト全体で共通的に利用されるインメモリリポジトリとアプリケーションインスタンスを準備します。
フィクスチャを用いることで、各テストケースに一貫した初期状態を提供し、テストコードの重複を排除できます。

import pytest
from bottle import Bottle
from webtest import TestApp

class InMemoryTaskRepository(TaskRepository):
    def __init__(self):
        self._tasks = {}

    def save(self, task: Task) -> None:
        self._tasks[task.task_id] = task

    def get_by_id(self, task_id: str) -> Task | None:
        return self._tasks.get(task_id)

@pytest.fixture
def task_repo():
    return InMemoryTaskRepository()

@pytest.fixture
def app(task_repo):
    application = Bottle()

    @application.put('/api/tasks/<task_id>/complete')
    def complete_task_endpoint(task_id, task_repo=task_repo):
        service = TaskService(task_repo)
        try:
            task = service.complete_task(task_id)
            return {
                "task_id": task.task_id,
                "title": task.title,
                "completed": task.completed
            }
        except ValueError:
            return {"error": "Task not found"}

    return TestApp(application)

webtest.TestAppは、実際にHTTPサーバーを起動することなく、WSGIアプリケーションに対してHTTPリクエストを模擬する優れたツールです。
これにより、統合テストは高速かつ確定的に実行されます。

HTTPステータスだけでなく境界を超えた振る舞いを検証するアサーション

統合テストにおいて最も避けるべきは、HTTPステータスコードの検証だけでテストを終えてしまう安易なアプローチです。
200 OKが返却されたからといって、タスクが実際に完了状態として永続化されたとは限りません。
振る舞いの検証とは、システムの外部に観測可能な副作用を確認することに他なりません。

以下のテストケースは、レスポンスの構造と、リポジトリ内部の状態変化の両方を検証します。

def test_complete_task_returns_updated_state(app, task_repo):
    task_repo.save(Task(task_id="t1", title="Write tests"))

    response = app.put_json('/api/tasks/t1/complete', {})

    assert response.status_int == 200
    assert response.json["completed"] is True

def test_complete_task_persists_change_to_repository(app, task_repo):
    task_repo.save(Task(task_id="t2", title="Refactor code"))

    app.put_json('/api/tasks/t2/complete', {})

    persisted = task_repo.get_by_id("t2")
    assert persisted is not None
    assert persisted.completed is True

このように、ハンドラの出力と永続化層の状態を両方検証することで、ユースケースが本当に責務を果たしたかを境界を超えて確認できます。
以下の表は、統合テストにおける検証の観点を整理したものです。

検証の観点	具体的な確認事項	設計上の意義
HTTPレスポンス	ステータスコードとボディの構造	プレゼンテーション層の契約を保証する
永続化状態	リポジトリ内のデータ変化	ユースケースの副作用を正しく検証する
エラー伝播	異常時のレスポンスと状態非変化	異常系における振る舞いの安定性を確認する

境界を超えたアサーションを徹底することで、テストは単なる実装のチェックサムではなく、システムの振る舞いに関する実行可能な仕様として機能します。

リファクタリング後も崩壊しないテストコードを維持する5つの設計ポイント

クリーンな設計とテストダブルの導入は、統合テストの健全性を回復するための重要な第一歩です。
しかし、設計が整ったからといって自動的にテストが保守可能になるわけではありません。
テストコード自体の品質、すなわち検証の対象と方法の選択が、長期的なメンテナンスコストを決定づけるからです。
なぜ、同じアプリケーションに対しても、あるテストはリファクタリングを乗り越えて生き残り、別のテストは些細な変更で崩壊してしまうのでしょうか。
その差は、テストが実装の詳細に結合しているか、あるいは振る舞いの契約に焦点を当てているかという設計上の選択にあります。

以下の表は、リファクタリング後も崩壊しないテストコードを維持するための5つの設計ポイントを整理したものです。

設計ポイント	目的	期待される効果
抽象への依存	実装詳細からテストを解放する	内部変更の影響を局所化できる
ブラックボックステストの徹底	公開インターフェースのみを検証する	内部構造の変更に対する耐性を獲得する
オブジェクトマザーの活用	テストデータ構築を共通化する	テストコードの重複を排除し可読性を向上させる
境界を超えたアサーション	観測可能な副作用を検証する	振る舞いの正確性を保証する
テストの独立性確保	テスト間の依存を排除する	実行順序に依存しない信頼性を担保する

これらのポイントは個別に効果を発揮しますが、相互に補完し合うことで、はじめて持続可能なテストスイートとして機能します。
特に、コンピューターサイエンスの観点から重視すべきは、テストコードもまたソフトウェアの一部であり、通常の実装コードと同様に、結合度を低く、凝集度を高く保つ設計が求められるということです。

公開インターフェースのみを検証対象とするブラックボックステストの徹底

ブラックボックステストとは、モジュールの内部構造ではなく、公開されているインターフェースとその入出力の関係のみを検証する手法です。
これは、情報隠蔽の原則と直接的に対応しており、モジュールの実装がどのように変更されようと、外部に対して保証された契約が維持されているかを確認します。
統合テストにおいてブラックボックスの視点を徹底することは、テストコードが実装の詳細に引きずられることを防ぐ最も効果的な手段です。

以下は、公開インターフェースのみを通じてタスクの完了操作を検証するテスト例です。

def test_complete_task_affects_observable_state(task_repo):
    task_repo.save(Task(task_id="t3", title="Review PR"))
    service = TaskService(task_repo)

    result = service.complete_task("t3")

    assert result.completed is True
    retrieved = task_repo.get_by_id("t3")
    assert retrieved.completed is True

このテストは、TaskServiceの内部でどのようなアルゴリズムが使われているか、あるいはTaskオブジェクトの属性がどの順序で更新されるかを一切知りません。
公開されているcomplete_taskメソッドとget_by_idメソッドという契約にのみ依存しています。
内部でプライベートメソッドを追加したり、データ構造を変更したりしても、このテストは崩壊しません。
これがブラックボックステストの本質的な強靭さです。

テストデータ構築パターンを共通化するオブジェクトマザーの活用

テストコードの可読性と保守性を損なう要因の一つに、テストデータの構築ロジックが各テストケースに散在することがあります。
コンストラクタの引数が増えた際に、数十のテストケースを一つずつ修正しなければならない状況は、コンピューターサイエンスのDRY原則に明らかに反しています。
オブジェクトマザーは、特定のドメインオブジェクトを意味のある初期状態で生成する責務を担うファクトリであり、テストデータ構築のパターンを一箇所に集約します。

以下は、タスクオブジェクトの生成を共通化するオブジェクトマザーの実装例です。

class TaskMother:
    @staticmethod
    def pending_task(task_id="t-pending", title="Pending Task"):
        return Task(task_id=task_id, title=title, completed=False)

    @staticmethod
    def completed_task(task_id="t-done", title="Completed Task"):
        return Task(task_id=task_id, title=title, completed=True)

このパターンを用いることで、テストケースはデータ構築の詳細から解放され、検証すべき振る舞いに集中できます。
たとえば、pending_taskのデフォルトタイトルが変更になっても、テストケース側を修正する必要は生じません。
オブジェクトマザーは、テストコードにおける結合度を下げ、データ構築という関心事の凝集度を高める、極めて実用的な設計技法です。

まとめ：Bottleの統合テストを持続可能に保つ設計の鉄則

Bottleのような軽量なWebフレームワークを用いた開発において、統合テストがリファクタリングのたびに崩壊する問題は、決して避けて通れない運命ではありません。
本稿で論じてきたように、この脆弱性の根源はハンドラ層とデータ層の密結合、すなわち実装の詳細への過度な依存にあります。
コンピューターサイエンスの基本的な教えに立ち返れば、優れたソフトウェアシステムとは、低結合かつ高凝集の状態を志向し、情報隠蔽と抽象化によって変更の影響を局所化したものです。
統合テストが持続可能であるための条件も、まさにこの設計原則の徹底にほかなりません。

本稿で提示した設計の鉄則は、以下の3つの柱に集約されます。

• 依存関係の逆転: ハンドラが具体的なデータアクセス実装に依存するのではなく、リポジトリのような抽象に依存させることで、テスト時の実装差し替えを可能にします
• レイヤーの分離: プレゼンテーション層、アプリケーション層、ドメイン層、インフラストラクチャ層という明確な境界を設けることで、HTTPの文脈からビジネスロジックを解放し、純粋な振る舞いの検証を実現します
• ブラックボックスの徹底: 公開インターフェースと観測可能な副作用のみを検証対象とし、実装の詳細にテストを結合させないことで、内部構造の進化に対する耐性を獲得します

以下の表は、本稿で議論した設計手法と、それが統合テストにもたらす具体的な効果を整理したものです。

設計の鉄則	解決する問題	テストへの効果
依存性注入とリポジトリパターン	データ層への密結合	インメモリ実装による高速で独立したテスト実行が可能になる
レイヤードアーキテクチャ	関心事の混在と責務の分散	ユースケース単位での純粋な振る舞い検証が可能になる
テストダブルの使い分け	外部リソースへの過度な依存	再現性のあるテスト環境を軽量に構築できる
ブラックボックステスト	実装詳細への脆弱な結合	リファクタリング後もテストが崩壊しにくくなる
オブジェクトマザー	テストデータ構築の重複と散在	データ構築の変更影響を局所化し可読性を向上させる

これらの原則は、一見すると開発初期のオーバーヘッドに思えるかもしれません。
しかし、ソフトウェア工学の長年の実践が示すように、設計への初期投資は中長期的な開発速度の向上と、技術的負債の蓄積防止に対して指数的なリターンをもたらします。
壊れやすいテストコードは、開発者の心理的負担を増大させ、やがてテストそのものが書かれなくなるという負のスパイラルを生み出します。
逆に、持続可能なテストスイートは、自信を持ったリファクタリングを可能にし、システムの進化を加速させる安全網として機能します。

Bottleの簡潔さは武器ですが、その自由度を無秩序に使えば、結合度の上昇という罠に陥りかねません。
フレームワークが設計上の決定を代行してくれないからこそ、開発者自身が意識的に境界を引き、抽象に依存し、関心事を分離する責務を負います。
本稿が、Bottleアプリケーションの統合テストをより堅牢でクリーンなものへと昇華させる一助となれば幸いです。