WordPressの単体テストで陥りがちなアンチパターンとグローバル変数の正しい扱い方

WordPressの単体テストにおいては、一般的なPHPアプリケーションとは異なる「グローバル依存の強さ」が障害となり、設計やテスト戦略を誤ると、テストが不安定かつ再現性の低いものになりがちです。
特にプラグインやテーマ開発では、WordPressコアが持つグローバル変数や暗黙的な状態に依存してしまい、単体テストの意義を損なうケースが少なくありません。

まず典型的なアンチパターンとして挙げられるのは、グローバル変数への直接依存です。
例えば $post や $wp_query に処理ロジックが強く結びついていると、テスト時に状態を適切に再現できず、テスト間での影響が発生します。
また、$_GET や $_POST に依存したロジックも同様に、入力の明示性を損ない可読性と保守性を低下させます。

さらに、以下のような設計も問題になりやすいです。

シングルトンへの過度な依存による状態共有
WordPress関数のラップなし直接呼び出しによるモック困難化
データベースやオプションAPIへの直接アクセスによる副作用の混入

単体テストの観点では、各テストケースが完全に独立した状態を持つことが重要ですが、WordPressはその構造上、グローバル状態の影響を完全に排除することが難しいフレームワークです。
そのため、WP_UnitTestCase の利用やファクトリパターンによるデータ生成、依存性の明示的注入といった設計上の工夫が不可欠になります。

また、グローバル変数の扱いについても単純に「避ける」だけでは不十分で、むしろ適切に分離・初期化・リセットする戦略が求められます。
WordPressの実行モデルを理解した上で、テストごとに状態を制御可能にすることが、安定したテスト設計の本質と言えるでしょう。

WordPress単体テストの基礎と重要性
WordPress特有の単体テストで発生する問題点
グローバル変数依存が引き起こすテストの不安定性
スーパーグローバル変数（$_GET $_POST）の危険な扱い方
シングルトンとサービスロケータパターンの落とし穴
WordPress関数の直接呼び出しとモック困難問題
WP_UnitTestCaseを使ったテスト環境構築の実践
依存性注入によるテスト可能な設計への改善
グローバル状態の初期化とリセット戦略
WordPress単体テストにおけるアンチパターンの総括

WordPress単体テストの基礎と重要性

WordPressの単体テストは、一般的なPHPアプリケーションにおけるテストと比較すると、やや特殊な性質を持っています。
その理由は、WordPress自体が強いグローバル依存構造を持ち、かつ実行時に多数のフックや状態を内部的に管理しているためです。
このため、純粋な関数単位のテストであっても、フレームワーク全体の影響を受けやすいという特徴があります。

単体テストの本質は「ある入力に対して期待される出力が一貫して得られること」を検証する点にあります。
しかしWordPressでは、データベース状態、オプション設定、グローバル変数、さらにはアクションフックの登録状況といった複数の外部要因が絡み合うため、この一貫性の担保が難しくなります。
その結果として、テストが環境依存になりやすく、CI環境とローカル環境で結果が異なるといった問題も発生します。

このような背景から、WordPress開発において単体テストを導入することは、単なる品質保証以上の意味を持ちます。
具体的には以下のような効果があります。

リファクタリング時の安全性向上
プラグインやテーマの副作用検出
長期運用における仕様劣化の防止
チーム開発での仕様共有の明確化

特にプラグイン開発では、外部のWordPressコアアップデートの影響を受けやすいため、単体テストが存在するかどうかで保守コストに大きな差が生まれます。
テストがない場合、変更の影響範囲をすべて人間が把握する必要があり、結果としてバグの混入リスクが指数関数的に増加します。

また、単体テストは「仕様のドキュメント」としても機能します。
例えば以下のようなコードを考えます。

function is_admin_user($user_id) {
    return user_can($user_id, 'manage_options');
}

この関数自体は単純ですが、WordPressの権限システムに依存しているため、テストを書くことで「どの権限が管理者扱いになるのか」という仕様を明文化できます。
これはドキュメントとしての価値を持ち、仕様変更時の影響分析にも寄与します。

さらに重要な点として、単体テストは設計改善のトリガーとして機能します。
テストを書こうとすると、自然と以下のような問題に気づくことになります。

関数がグローバル状態に依存しすぎている
入力と出力の関係が不明確
副作用が隠蔽されている

これらの問題は、そのままコードの保守性や可読性の低下につながるため、テスト導入は結果的にアーキテクチャ改善を促進します。

WordPressにおける単体テストの基礎を理解する上で重要なのは、「テストは検証手段であると同時に設計ツールである」という視点です。
この視点を持つことで、単なる品質保証を超えて、より構造的で安定したコードベースを構築することが可能になります。

WordPress特有の単体テストで発生する問題点

WordPressの単体テストを設計する際、最初に直面するのは「通常のPHP単体テストとは前提条件が異なる」という構造的な問題です。
一般的なアプリケーションであれば、関数やクラスを独立してテストすることが比較的容易ですが、WordPressの場合は実行環境そのものが巨大な状態管理システムとして動作しているため、その前提が成立しにくくなります。

この特性により、テストの難易度は実装の複雑さ以上に「環境依存性」によって決定される傾向があります。
特に以下のような問題が頻出します。

WordPressコアのロード順に依存するテストの不安定性
グローバル変数の初期化状態による結果の揺らぎ
フック（action/filter）の登録状態による挙動差分
データベースの残存データによるテスト間干渉

これらは単体テストの基本原則である「独立性」と「再現性」を直接破壊する要因となります。
例えば同じテストコードであっても、実行順序が異なるだけで結果が変わるケースは珍しくありません。
これは純粋なアルゴリズムテストではほとんど見られない現象です。

特に厄介なのは、WordPressのフックシステムによる副作用です。
以下のようなケースを考えます。

add_action('init', function() {
    update_option('sample_flag', true);
});

このようなコードが存在すると、テスト実行時にinitフックが発火するかどうかで状態が変化し、テストの前提条件そのものが揺らぎます。
結果として、テストケースが「実装の正しさ」ではなく「実行コンテキストの正しさ」に依存してしまいます。

また、WordPressのデータベース抽象化層も問題の一因となります。
本来であればモック可能なレイヤーとして扱うべきですが、get_optionやupdate_optionといった関数がグローバルに露出しているため、設計上の分離が難しくなります。
この構造はテスト容易性の観点から見ると明確なアンチパターンです。

さらに、以下のようなテスト設計上の問題も発生します。

問題領域	具体的症状	影響
グローバル状態	テスト間の干渉	再現性低下
フック依存	実行順序依存バグ	不安定なCI結果
DB依存	テストデータ汚染	テスト分離不能
コア依存	バージョン差異	環境差分バグ

これらの問題が複合的に絡むことで、WordPressの単体テストは「単体」の定義自体が曖昧になりがちです。
本来の単体テストはロジック単位の検証であるべきですが、WordPressではフレームワーク全体を軽量に起動した統合テストに近い形になりやすいという現実があります。

重要なのは、この特性を「欠陥」として捉えるのではなく、「前提条件」として受け入れた上で設計を調整することです。
例えば、ビジネスロジックをWordPress依存から分離することで、テスト対象を純粋なPHPコードとして切り出すことが可能になります。
このような分離設計ができるかどうかが、テストの安定性を大きく左右します。

したがって、WordPress特有の単体テスト問題は単なる技術的課題ではなく、アーキテクチャ設計の成熟度そのものを反映する指標であると言えます。

グローバル変数依存が引き起こすテストの不安定性

WordPressにおける単体テストの難所として最も本質的かつ厄介なのが、グローバル変数への依存です。
PHPという言語自体がグローバルスコープを比較的容易に扱える設計になっているため、WordPressはその上にさらに状態管理のレイヤーを重ねています。
その結果、アプリケーション全体が「共有状態の集合」として振る舞う構造になりやすく、テストの再現性が著しく損なわれます。

単体テストにおいて重要なのは、入力と出力の関係が明確であり、同じ入力に対して常に同じ出力が得られることです。
しかしグローバル変数が関与すると、この前提が簡単に崩壊します。
例えば $post、$wp_query、$wpdb といったコア変数は、実行コンテキストに依存して内容が変化するため、テストケースごとに完全な初期化を行わなければ結果が揺らぎます。

特に問題となるのは、以下のような状況です。

テストケース間でグローバル状態が共有されてしまう
テストの実行順序によって結果が変化する
初期化処理の漏れにより前回の状態が残存する
フレームワーク側の副作用がテストに波及する

これらの問題は単なる実装ミスではなく、構造的な設計問題として捉える必要があります。
なぜなら、WordPressはもともとリクエスト単位での実行を前提としており、プロセス内での状態分離を厳密に行う設計になっていないためです。

具体例として、以下のようなケースを考えます。

global $wp_query;
$wp_query->set('post_type', 'page');
$wp_query->query();

このようなコードは一見すると単純ですが、テスト環境では重大な問題を引き起こします。
$wp_queryはリクエスト全体のクエリ状態を保持するため、別のテストで同じグローバル変数を参照した場合、前回の状態が残っている可能性があります。
これにより、テストは「独立した検証単位」ではなく「状態遷移の連続」に変質してしまいます。

また、グローバル変数依存はモックの難易度を著しく上昇させます。
本来であれば依存関係はインターフェース越しに注入されるべきですが、WordPressでは関数呼び出しとしてグローバル状態に直接アクセスするケースが多く、差し替えが困難です。
この結果として、テストコード側が本来の設計を歪めてしまう「テスト駆動の逆転現象」が発生することがあります。

さらに、グローバル状態はデバッグの難易度も上昇させます。
あるテストが失敗した際、その原因が当該テスト内にあるのか、それとも以前のテストによって汚染された状態にあるのかを切り分ける必要があるためです。
この調査コストはテストケース数が増えるほど指数的に増加します。

この問題を整理すると、グローバル変数依存は以下の三つの本質的なリスクに帰結します。

リスク種別	内容	影響
再現性低下	同一入力でも結果が変わる	信頼性低下
状態汚染	テスト間の副作用共有	独立性喪失
設計硬直化	モック困難による制約	拡張性低下

重要なのは、これらの問題は単にテスト技法で解決できるものではないという点です。
むしろ、設計レベルでグローバル依存を制御する必要があります。
具体的には、ビジネスロジックをWordPressのグローバル空間から切り離し、純粋なPHPオブジェクトとして扱うことが有効です。

このように考えると、グローバル変数依存は単なるコードの癖ではなく、アーキテクチャ全体の品質を規定する中心的な要素であることが理解できます。
したがって、単体テストの安定性を確保するためには、この依存構造そのものに対する設計的アプローチが不可欠になります。

スーパーグローバル変数（$_GET $_POST）の危険な扱い方

WordPressの単体テストにおいて見落とされがちですが、実務上非常に影響が大きいのがスーパーグローバル変数である $_GET や $_POST の扱いです。
これらはPHPの実行環境に直接結びついた入力データであり、リクエストごとに変化するため、テスト設計の観点では「暗黙的な外部依存」として扱う必要があります。

単体テストの基本原則は、入力を明示的に制御し、外部状態に依存しないことです。
しかしスーパーグローバル変数を直接参照する設計では、この原則が容易に破綻します。
例えば以下のようなコードは典型的なアンチパターンです。

function get_user_id_from_request() {
    return isset($_GET['user_id']) ? intval($_GET['user_id']) : 0;
}

この関数は一見シンプルですが、テスト時には $_GET の状態を事前に操作する必要があり、テストケース間の独立性が損なわれます。
さらに問題なのは、実行順序や他テストの影響で $_GET が汚染される可能性がある点です。

スーパーグローバル変数の危険性は主に以下の観点に整理できます。

テスト対象の入力が暗黙的で可視性が低い
テストケースごとに環境初期化が必要になる
並列実行時に状態競合が発生しやすい
セキュリティ上の意図しない入力混入リスク

特にCI環境においては、テストが並列実行されるケースが多く、$_POST や $_GET のようなプロセス共有変数は予期せぬ干渉を引き起こす可能性があります。
これは単なるバグではなく、設計上の構造的問題です。

また、WordPressのフォーム処理や管理画面ロジックでは、スーパーグローバル変数に直接依存したコードが多く見られます。
例えば以下のようなケースです。

if ($_POST['action'] === 'save_settings') {
    update_option('my_plugin_setting', $_POST['value']);
}

このような実装は、入力検証の観点でもテストの観点でも問題を含んでいます。
まず入力が関数の外部にあるため、関数単体としての純粋性が失われています。
また、update_option のような副作用が直接発生するため、テストではモックや分離が必要になりますが、設計が密結合であるため難易度が上がります。

さらに重要なのは、スーパーグローバル変数は「実行時コンテキストに強く依存する」という点です。
これにより以下のような問題が発生します。

問題領域	具体的影響	テスト上の課題
入力依存	関数の再現性低下	同一テストでも結果が変動
状態汚染	他テストへの影響	テスト独立性の崩壊
可読性低下	入力経路の不明瞭化	仕様理解コスト増大

この問題を構造的に解決するためには、スーパーグローバル変数への直接依存を排除し、入力を関数の引数として明示的に受け取る設計へ移行する必要があります。
例えば先ほどの例は以下のように改善できます。

function get_user_id_from_request(array $request) {
    return isset($request['user_id']) ? intval($request['user_id']) : 0;
}

このように設計を変更することで、テストは $_GET に依存せず、純粋な入力データを渡すだけで成立します。
これは単体テストの再現性と独立性を大幅に向上させる基本的かつ重要な改善です。

結論として、スーパーグローバル変数の直接利用は短期的には便利ですが、長期的にはテスト容易性と保守性を著しく損ないます。
そのため、WordPress開発においては「グローバル依存の排除」ではなく「依存の明示的な制御」が本質的な設計指針となります。

シングルトンとサービスロケータパターンの落とし穴

WordPress開発において設計の複雑性を増幅させる要因の一つが、シングルトンパターンおよびサービスロケータパターンの過剰な利用です。
これらは一見すると便利な依存管理手法であり、特にプラグイン開発では「どこからでも同じインスタンスにアクセスできる」という利点から広く採用されがちです。
しかし単体テストの観点から見ると、この設計はテスト容易性を大きく損なう典型的なアンチパターンになり得ます。

シングルトンパターンの本質的な問題は、「状態の共有」と「インスタンス生成の制御不能性」にあります。
通常のオブジェクトであれば、テストごとに新しいインスタンスを生成し、状態を完全に独立させることが可能です。
しかしシングルトンではグローバルに単一インスタンスが保持されるため、テスト間で状態が共有されてしまいます。

例えば以下のような実装を考えます。

class Config {
    private static $instance = null;
    private $settings = [];
    private function __construct() {}
    public static function getInstance() {
        if (self::$instance === null) {
            self::$instance = new Config();
        }
        return self::$instance;
    }
    public function set($key, $value) {
        $this->settings[$key] = $value;
    }
    public function get($key) {
        return $this->settings[$key] ?? null;
    }
}

このような設計では、一度設定された状態がテストケース間で残存する可能性があり、テストの独立性が崩壊します。
特にCI環境でテストが順不同に実行される場合、結果の再現性が保証されなくなります。

一方、サービスロケータパターンは依存性を中央集約的に管理する設計ですが、これもまたテスト観点では問題を抱えています。
理由は、依存関係がコード上で明示されず、実行時に解決されるためです。
この「隠れた依存関係」は、コードの可読性だけでなくテスト設計の透明性も損ないます。

問題点を整理すると以下のようになります。

依存関係がコードから見えなくなる
テスト時のモック差し替えが困難になる
グローバル状態として振る舞いが固定化される
初期化順序に強く依存する構造になる

特にWordPressでは、プラグイン間でサービスロケータ的な仕組みを独自実装しているケースが多く見られますが、これがテストの複雑性をさらに増幅させます。

また、両者に共通する本質的な問題は「状態のライフサイクルが制御不能になる」という点です。
本来であれば、オブジェクトの生成・破棄・初期化はテスト単位で明確に制御されるべきですが、シングルトンやサービスロケータではその制御権がアプリケーション全体に分散してしまいます。

比較すると以下のようになります。

設計手法	状態管理	テスト容易性	依存の明示性
シングルトン	グローバル共有	低い	低い
サービスロケータ	中央集約	中程度（ただし複雑）	低い
DI（依存性注入）	インスタンス単位	高い	高い

この比較からも明らかなように、テスト容易性の観点では依存性注入が最も合理的な選択肢となります。

さらに重要なのは、これらのパターンが「短期的な利便性」と引き換えに「長期的な保守性とテスト性」を犠牲にしている点です。
特にWordPressのように拡張性が高く、プラグイン同士の相互作用が発生し得る環境では、この設計選択の影響は時間とともに指数的に増大します。

したがって、シングルトンおよびサービスロケータは単なる設計パターンではなく、アーキテクチャ全体のテスト戦略に直結する重要な判断要素であると捉える必要があります。
単体テストを安定させるためには、これらのパターンを「便利だから使う」のではなく、「本当に必要な場合に限定して使用する」という制約付きで扱うことが求められます。

WordPress関数の直接呼び出しとモック困難問題

WordPressの単体テストにおいて設計上の大きな障壁となるのが、WordPressコア関数への直接依存です。
特に get_option、update_option、wp_insert_post といった関数はグローバル空間に存在し、どこからでも呼び出せる一方で、テスト時の差し替え（モック化）が極めて困難という特徴を持っています。

本来、単体テストでは外部依存を排除し、テスト対象のロジックのみを検証可能な状態にすることが理想です。
しかしWordPress関数は設計上フレームワークの中心に組み込まれているため、依存を抽象化するレイヤーが存在しないまま直接呼び出されるケースが多く見られます。
この構造がテストの分離性を著しく損ないます。

例えば以下のようなコードは典型的な問題例です。

function save_user_setting($user_id, $value) {
    update_user_meta($user_id, 'setting_key', $value);
    return get_user_meta($user_id, 'setting_key', true);
}

この関数は一見単純ですが、内部でWordPressの永続化層に直接依存しています。
そのため単体テストでは以下の問題が発生します。

データベース状態に依存するため再現性が低い
モック対象が存在せずテストが統合テスト化する
実行環境により結果が変化する可能性がある
テスト実行速度が遅くなる

特に問題となるのは「モックの困難さ」です。
通常のオブジェクト指向設計であればインターフェースを切り替えることで依存を差し替えることができますが、WordPress関数はグローバル関数として定義されているため、テストフレームワーク側でのフックやリプレースが必要になります。
この追加レイヤーがテスト設計を複雑化させます。

また、WordPress関数は内部的にグローバル状態やデータベースアクセスを伴うことが多く、単純なスタブでは代替できないケースが存在します。
例えば wp_insert_post は投稿作成だけでなくフック実行やキャッシュ更新も同時に行うため、完全な振る舞いの再現は困難です。

この問題を整理すると、以下の三つの構造的課題に集約されます。

課題	内容	影響
直接依存	関数呼び出しが抽象化されていない	モック困難
副作用の多重性	DB・フック・キャッシュ更新が同時発生	再現性低下
グローバル結合	状態がフレームワーク全体に波及	テスト分離不能

これらの問題は単なるテスト技術では解決できず、設計レベルでの介入が必要になります。
具体的には、WordPress関数を直接呼び出すのではなく、ラッパー関数やサービスクラスを介して依存を抽象化する方法が有効です。

例えば次のような構造に変更します。

class UserRepository {
    public function save_setting($user_id, $value) {
        update_user_meta($user_id, 'setting_key', $value);
    }
    public function get_setting($user_id) {
        return get_user_meta($user_id, 'setting_key', true);
    }
}

このようにラップすることで、テスト時には UserRepository 自体をモック対象にすることが可能となり、WordPress関数への直接依存を排除できます。
これにより単体テストの粒度を適切に維持することができます。

さらに重要なのは、この設計変更が単なるテスト容易性の改善にとどまらず、アーキテクチャ全体の分離度を向上させる点です。
WordPress関数への直接依存を排除することで、ビジネスロジックとフレームワーク依存が明確に分離され、将来的な移植性や拡張性も高まります。

結論として、WordPress関数の直接呼び出しは短期的には開発効率を高めますが、長期的にはテスト困難性と保守コストを増大させます。
そのため、単体テストを安定させるためには「関数を使うかどうか」ではなく、「どの層で依存を制御するか」という設計判断が本質的に重要になります。

WP_UnitTestCaseを使ったテスト環境構築の実践

WP_UnitTestCaseを用いたWordPressテスト環境構築のイメージ

WordPressにおける単体テスト環境の構築では、標準的なPHPUnitの知識だけでは不十分であり、WordPress専用のテスト基盤である WP_UnitTestCase の理解と活用が不可欠になります。
このクラスはWordPressコアが提供するテストフレームワークの基盤であり、実際のWordPress環境に近い状態を再現しつつテストを実行できるよう設計されています。

通常のPHPUnitでは、テスト対象は純粋なPHPコードとして扱われ、フレームワーク依存は最小限に抑えられます。
しかしWordPressでは、グローバル変数、フックシステム、データベースアクセスといった要素が密接に絡み合っているため、それらを完全に無視したテストは現実的ではありません。
そのため WP_UnitTestCase は、WordPressのブートストラップ処理を含んだ状態でテストを実行する仕組みを提供しています。

このクラスを使用することで、以下のような環境が自動的に準備されます。

WordPressコアのロード
テスト用データベースの初期化
フックおよびアクションの登録管理
グローバル変数の初期状態の設定

これにより、開発者はWordPress特有の環境構築処理を意識せずにテストコードの記述に集中できます。

基本的なテストクラスは以下のように構成されます。

class SampleTest extends WP_UnitTestCase {
    public function test_example_option() {
        update_option('sample_key', 'value');
        $this->assertEquals('value', get_option('sample_key'));
    }
}

この例から分かるように、WP_UnitTestCase を継承することで、WordPressの関数群をそのまま利用したテストが可能になります。
ただしこの「そのまま使える」という特性は便利である一方で、設計の自由度を低下させる側面も持っています。
つまり、テスト容易性をフレームワーク側の仕組みに依存してしまうため、設計改善の機会を見逃すリスクが存在します。

また、WP_UnitTestCase にはテストデータ生成を支援するファクトリ機能が含まれています。
これにより投稿、ユーザー、タクソノミーなどのテストデータを簡単に生成できます。

$user_id = $this->factory->user->create([
    'role' => 'editor'
]);
$post_id = $this->factory->post->create([
    'post_author' => $user_id
]);

この仕組みにより、実際のWordPress環境に近いデータ構造を再現しながらテストを実行できます。
しかし同時に、このファクトリに依存しすぎるとテストがWordPress実装詳細に強く結びついてしまい、純粋なユニットテストではなく統合テスト寄りになるというトレードオフも存在します。

ここで重要なのは、WP_UnitTestCase を「万能な解決策」として扱わないことです。
むしろ以下のような観点で適切に使い分ける必要があります。

観点	WP_UnitTestCase適合性	補足
WordPress依存ロジック	高い	必須利用
ビジネスロジック	中程度	分離推奨
純粋関数ロジック	低い	PHPUnit単体で十分

特に設計上重要なのは、WordPress依存部分と純粋ロジックを明確に分離することです。
これを怠ると、すべてのテストが WP_UnitTestCase 前提となり、テスト実行速度や保守性が低下します。

さらに実務上では、テストの初期化コストも考慮する必要があります。
WP_UnitTestCase はWordPress全体をロードするため、テストの実行時間が増加しやすく、大規模プロジェクトではCIパイプラインのボトルネックになることもあります。

したがって、実践的なアプローチとしては以下が推奨されます。

純粋ロジックはPHPUnit単体でテスト
WordPress依存部分のみWP_UnitTestCaseで検証
依存を最小化する設計を優先

このように役割を明確に分離することで、テストの安定性と実行効率を両立できます。
WP_UnitTestCase は非常に強力なツールですが、それ自体が設計の代替手段になるわけではなく、あくまでWordPress特有の制約を補うための基盤であるという理解が重要です。

依存性注入によるテスト可能な設計への改善

WordPressの単体テストにおける根本的な課題は、コードがフレームワークに強く結合しすぎている点にあります。
特にグローバル関数やスーパーグローバル変数、シングルトン構造に依存した設計では、テスト対象の切り出しが困難になり、結果としてテストが「環境そのもの」に依存する形になってしまいます。
この問題を解決するための中心的なアプローチが依存性注入（Dependency Injection）です。

依存性注入の本質は、オブジェクトや関数が必要とする依存関係を内部で生成するのではなく、外部から明示的に渡す点にあります。
これにより、クラスや関数は特定の実装に依存せず、抽象化されたインターフェースやデータ構造にのみ依存することが可能になります。

例えば、従来のWordPress的な設計では以下のようなコードが一般的です。

function get_user_display_name($user_id) {
    $user = get_userdata($user_id);
    return $user->display_name;
}

この設計では get_userdata というWordPress関数に直接依存しているため、テスト時にこの関数の挙動を制御することが困難です。
一方で依存性注入を導入すると、次のように設計を変更できます。

class UserService {
    private $userRepository;
    public function __construct($userRepository) {
        $this->userRepository = $userRepository;
    }
    public function getDisplayName($user_id) {
        $user = $this->userRepository->find($user_id);
        return $user['display_name'] ?? null;
    }
}

このように設計を変更することで、WordPress関数への直接依存を排除し、テスト可能な構造へと変換できます。
テスト時には userRepository をモックオブジェクトとして差し替えることができるため、外部環境に依存しない純粋な単体テストが可能になります。

依存性注入の導入によって得られる利点は複数あります。

テスト対象のロジックが純粋化される
外部依存をモックで制御可能になる
クラス単位での責務が明確化される
再利用性と拡張性が向上する

特にWordPressのようなフレームワークでは、データベースアクセスやフック処理が内部に隠蔽されているため、これらを直接呼び出す設計ではテストの分離性が著しく低下します。
依存性注入はこの問題を構造的に解決する手段として非常に有効です。

また、依存性注入は単にテスト容易性を高めるだけではなく、設計そのものを改善する効果も持ちます。
依存関係が明示化されることで、クラスの責務が自然と単純化され、結果としてコードの可読性や保守性も向上します。

ただし、依存性注入にも注意点があります。
過剰に適用するとコンストラクタが肥大化し、依存関係の管理が複雑になる場合があります。
そのため、適用範囲を適切に設計することが重要です。

観点	依存性注入導入前	依存性注入導入後
テスト容易性	低い	高い
依存の明示性	暗黙的	明示的
モック可能性	困難	容易
設計の柔軟性	低い	高い

このように比較すると、依存性注入は単なるテスト技法ではなく、アーキテクチャ設計の中心的な原則であることが分かります。

結論として、WordPress開発における単体テストの安定性を確保するためには、フレームワークに依存した設計から脱却し、依存性を明示的に制御する構造へ移行することが不可欠です。
依存性注入はそのための最も基本的かつ効果的な手段であり、長期的な保守性とテスト容易性の両立を実現する鍵となります。

グローバル状態の初期化とリセット戦略

WordPressの単体テストにおいて最も厄介な問題の一つが、グローバル状態の残存とそれに伴うテスト間干渉です。
WordPressはリクエスト単位での実行を前提としたアーキテクチャを持つため、プロセス内で状態を完全に隔離する設計にはなっていません。
その結果、テスト環境では「前のテストの影響が次のテストに残る」という問題が頻繁に発生します。

この問題を解決するためには、単にテストコードを工夫するだけでは不十分であり、グローバル状態そのものを意識的に初期化・リセットする戦略が必要になります。

まず理解すべきは、WordPressにおけるグローバル状態の範囲です。
代表的なものとして以下が挙げられます。

$wp_query（メインクエリ状態）
$post（現在の投稿オブジェクト）
$wpdb（データベース接続インスタンス）
フック登録情報（action / filter）
オプションキャッシュ

これらはすべてプロセス内で共有されるため、テスト間で明示的にリセットしない限り状態が保持されます。

典型的な問題として、以下のようなケースがあります。

global $wp_query;
$wp_query->set('post_type', 'post');
$wp_query->query();
$this->assertTrue($wp_query->is_main_query());

このようなテストは単体では正しく動作していても、別のテストで $wp_query が変更されている場合、予期しない結果を引き起こす可能性があります。
これはテストの独立性を破壊する典型例です。

この問題に対処するための基本戦略は大きく3つに分類できます。

1. テストごとの完全リセット

最も直接的な方法は、各テストの前後でグローバル状態を明示的に初期化することです。
setUp() と tearDown() を活用し、状態をリセットします。

public function tearDown(): void {
    global $wp_query, $post;
    $wp_query = null;
    $post = null;
    parent::tearDown();
}

この方法は単純ですが、WordPress全体の状態を完全に把握していないと不完全なリセットになる危険があります。

2. WordPressテストフレームワークの活用

WP_UnitTestCase は内部的にクリーンアップ処理を提供していますが、それでも完全な隔離は保証されません。
特にフックやオプションキャッシュは残存する場合があるため、補助的なリセット処理が必要になることがあります。

3. 状態を持たない設計への移行

最も本質的な解決策は、そもそもグローバル状態に依存しない設計へ移行することです。
ビジネスロジックをWordPress依存から分離し、純粋な関数やクラスとして設計することで、リセット自体の必要性を減らすことができます。

この観点から見ると、グローバル状態のリセットは「対症療法」であり、設計改善は「根本治療」と位置づけられます。

比較すると以下のようになります。

戦略	安定性	保守性	実装コスト
手動リセット	中	低	低
WP_UnitTestCase依存	中	中	低
状態非依存設計	高	高	高

重要なのは、リセット戦略に依存しすぎるとテストコード自体が複雑化し、本来の目的である「ロジック検証」が埋もれてしまう点です。
そのため、リセット処理はあくまで補助的手段として扱うべきです。

最終的に目指すべき状態は、グローバル状態を意識せずともテストが成立する設計です。
これは単なるテスト技法ではなく、アーキテクチャレベルでの設計品質の指標でもあります。
WordPress開発においては、この視点を持つことでテストの安定性とコードの健全性を同時に高めることが可能になります。

WordPress単体テストにおけるアンチパターンの総括

WordPressにおける単体テスト設計を俯瞰すると、その難しさの本質は個々の実装テクニックではなく、フレームワークそのものが持つアーキテクチャ特性に起因していることが分かります。
特にグローバル状態依存、関数ベースの設計、フックシステムによる暗黙的副作用といった要素が複雑に絡み合い、純粋な単体テストの成立を阻害しています。

本記事で扱ってきたアンチパターンは一見すると個別の問題に見えますが、実際にはすべて「依存関係の不透明性」という共通の構造問題に収束します。
すなわち、入力・出力・副作用の境界が曖昧であることが、テストの不安定性を生み出す根本要因です。

これまでの内容を整理すると、主なアンチパターンは以下のように分類できます。

グローバル変数への直接依存
スーパーグローバル変数の暗黙利用
シングルトンおよびサービスロケータの乱用
WordPress関数への直接呼び出し
グローバル状態の未管理および初期化不足

これらに共通する問題は、いずれも「依存関係がコード上で明示されていない」という点です。
この状態では、テストは実装の詳細に強く結びつき、環境依存性を排除することが困難になります。

特に重要なのは、これらのアンチパターンが単体テストの失敗を直接引き起こすのではなく、テスト設計そのものを統合テスト寄りに変質させてしまう点です。
その結果、テストは高速かつ独立した検証手段ではなく、重いフレームワーク依存の検証プロセスへと変化します。

この問題を構造的に理解するために、影響を整理すると以下のようになります。

アンチパターン	直接的影響	長期的影響
グローバル依存	状態汚染	テスト不安定化
関数直接呼び出し	モック困難	設計硬直化
シングルトン	状態共有	拡張性低下
スーパーグローバル	入力不明確	再現性低下

このように見ると、問題の本質はコードレベルではなく設計レベルに存在していることが明確になります。

したがって、単体テストの改善はテストコードの工夫だけでは不十分であり、アーキテクチャそのものの見直しが必要になります。
特に重要なのは以下の三点です。

依存関係の明示化
状態管理の局所化
副作用の分離

これらを徹底することで、テストは初めて安定した単位として機能します。

最終的に、WordPressにおける単体テストの課題は「テスト技法の問題」ではなく「設計思想の問題」です。
アンチパターンを回避することは目的ではなく、より重要なのはテスト可能な構造を持つシステム設計を実現することです。
この視点を持つことで、単体テストは単なる品質保証手段ではなく、設計品質を可視化するための強力なフィードバックループとして機能するようになります。