TypeScriptでの依存性注入のテスト方法とモックの活用法

TypeScriptにおける依存性注入（DI）は、クラスやコンポーネントが必要とする依存オブジェクトを外部から注入する手法です。このパターンにより、コードのモジュール性が向上し、特にテストの際には大きな利点をもたらします。DIを使用することで、テスト時に依存オブジェクトをモックに置き換えることが容易となり、独立したユニットテストが可能になります。

本記事では、TypeScriptでの依存性注入の基本から、そのテスト手法、さらにモックの使用方法について詳しく解説します。テストを効率的かつ正確に行うための重要な概念と実践例を交えながら進めていきます。

依存性注入（DI）とは

依存性注入（DI）とは、オブジェクトが他のオブジェクトやサービスに依存する場合、その依存関係を外部から注入する設計パターンです。通常、依存性はクラス内部で直接生成されることが多いですが、DIを使用することで、依存性をコンストラクタやメソッドを通じて外部から注入できるようになります。

依存性注入のメリット

DIの主なメリットは以下の通りです:

• 疎結合：依存オブジェクトを外部から渡すことで、クラス間の結合度が下がり、コードの再利用性とテストの容易さが向上します。
• テストのしやすさ：依存するオブジェクトを簡単にモックに差し替えられるため、単体テストやモジュールテストがより効果的に行えます。
• メンテナンスの簡易化：依存関係を外部で管理するため、後で異なる実装に置き換えることが容易です。

DIは、テスト可能でメンテナンス性の高いコードを書くための重要な設計パターンです。

テストにおけるDIの重要性

依存性注入（DI）は、テスト可能なコードを構築する上で非常に重要な役割を果たします。特にユニットテストやモジュールテストにおいて、DIを使用することで依存するオブジェクトを容易に差し替えたり、テストの対象となるコンポーネントを独立させて評価することができます。

DIがテスト設計に与える影響

DIはテストの設計に大きな影響を与えます。通常、依存性が直接内部で生成される場合、依存オブジェクトに強く結合してしまい、ユニットテストが困難になります。しかし、DIを利用すると依存オブジェクトをモックやスタブに置き換えることが可能になり、実際の外部サービスやデータベース接続に依存せずにテストを行うことができます。

DIを使用するテストの利点

DIを使ったテストの主な利点は以下の通りです：

• テストの独立性：テスト対象のクラスが依存オブジェクトに影響されないため、純粋にそのクラスの動作だけを検証できます。
• 外部システムからの独立：データベースやAPIなど、外部システムをモックで置き換え、テストの効率を上げることができます。
• テストのスピード向上：外部リソースへの依存がないため、テストは高速に実行されます。

依存性注入は、テスト可能で拡張性のあるシステムを構築するために、不可欠な設計パターンです。

モックとは何か

モック（Mock）とは、テスト時に依存するオブジェクトの振る舞いを模倣するためのダミーオブジェクトです。テストの対象となるクラスやコンポーネントが、外部の依存性に依存している場合、その依存性をモックで置き換えることで、外部の影響を排除し、対象クラスの動作のみを検証できるようにします。

モックの役割

モックは主に次の役割を果たします：

• 外部依存性の除去：データベースや外部APIなど、外部の依存リソースにアクセスせずにテストを実行できます。
• テストの精度向上：モックを使うことで、依存オブジェクトの動作を完全に制御でき、予測可能な結果でテストを実行できます。
• エラーシナリオの再現：実際のシステムでは再現が難しいエラーや例外の発生を、モックを使うことで簡単にシミュレーションできます。

依存性注入におけるモックの活用

依存性注入を使用しているコードでは、モックの使用が非常に簡単です。依存するオブジェクトを外部から注入する設計になっているため、テスト時にそのオブジェクトをモックに差し替えるだけで済みます。これにより、テスト時に外部リソースへの依存を排除し、テストの独立性とスピードを向上させることが可能です。

モックは、依存性注入と組み合わせることで、テストを効率的に行うための強力なツールとなります。

TypeScriptでのモック作成方法

TypeScriptでは、モックを作成することで依存するオブジェクトを仮のオブジェクトに置き換え、実際の動作を模倣することができます。これにより、外部サービスやデータベースなどに依存しないテストを実行できます。TypeScriptでモックを作成する際には、Jestなどのテストフレームワークを利用することが一般的です。

手動でのモック作成

TypeScriptでは、手動でモックを作成することが可能です。例えば、依存するサービスをインターフェースとして定義し、そのインターフェースを実装するモックを作成することができます。

// 依存するサービスのインターフェース
interface UserService {
  getUser(id: number): Promise<User>;
}

// モックの実装
const mockUserService: UserService = {
  getUser: jest.fn().mockResolvedValue({ id: 1, name: "Mock User" })
};

この例では、UserServiceをモックとして実装し、getUserメソッドは常にダミーのユーザーを返すように設定されています。

Jestを使ったモックの自動生成

Jestには、モックを自動的に生成する機能があります。jest.mock()を使用することで、依存モジュール全体を簡単にモック化できます。

// モジュールのモック化
jest.mock('./UserService', () => ({
  getUser: jest.fn().mockResolvedValue({ id: 1, name: "Mock User" })
}));

この方法では、getUserメソッドがモックされ、任意のテストデータを返すように設定できます。

モックのカスタマイズ

テストケースごとに異なる結果を返す必要がある場合、JestのmockReturnValueやmockImplementationを使ってモックの動作をカスタマイズすることができます。

// テスト内でモックをカスタマイズ
mockUserService.getUser.mockImplementation((id: number) => {
  return Promise.resolve({ id, name: `Mock User ${id}` });
});

このように、テストシナリオに応じてモックの挙動を柔軟に変更することができます。

TypeScriptでのモック作成は、手動やJestを使用して行え、テストの効率を大幅に向上させることができます。

Jestを使用した依存性注入のテスト

JestはTypeScriptプロジェクトで広く使われているテストフレームワークで、モック機能が強力であるため、依存性注入（DI）のテストに最適です。依存するオブジェクトをモックに置き換えることで、Jestを使ったテストはより簡潔で効率的に行えます。ここでは、依存性注入をJestでテストする方法について解説します。

Jestのセットアップ

まず、TypeScriptプロジェクトにJestを導入するためには、以下のパッケージをインストールします。

npm install --save-dev jest ts-jest @types/jest

ts-jestを使うことで、TypeScriptファイルをJestで直接テストできるようになります。次に、Jestの設定を行います。jest.config.jsを作成し、以下の設定を記述します。

module.exports = {
  preset: 'ts-jest',
  testEnvironment: 'node',
};

これで、TypeScriptファイルのテスト準備が整いました。

依存性注入のテスト準備

例えば、以下のような依存性注入を使うクラスをテストする場合を考えます。UserServiceに依存するUserControllerをテスト対象とします。

class UserController {
  constructor(private userService: UserService) {}

  async getUserData(id: number) {
    const user = await this.userService.getUser(id);
    return user;
  }
}

UserServiceが依存するオブジェクトであり、これをモック化してテストします。

依存オブジェクトのモック化

Jestを使って依存オブジェクトをモックに置き換えます。以下は、UserServiceをモックし、UserControllerのテストを行う例です。

// UserServiceのモック
const mockUserService = {
  getUser: jest.fn().mockResolvedValue({ id: 1, name: "Mock User" })
};

describe('UserController', () => {
  let userController: UserController;

  beforeEach(() => {
    // モックされたUserServiceを注入
    userController = new UserController(mockUserService);
  });

  it('should return user data', async () => {
    const result = await userController.getUserData(1);
    expect(result).toEqual({ id: 1, name: "Mock User" });
    expect(mockUserService.getUser).toHaveBeenCalledWith(1);
  });
});

テスト実行

テストを実行するには、以下のコマンドを使用します。

npm test

このテストでは、UserServiceが依存しているため、本来は外部リソースにアクセスする必要がありますが、モックを使うことでその依存性を排除し、効率的にテストを行っています。また、toHaveBeenCalledWith()を使用して、正しい引数でメソッドが呼ばれたことも確認しています。

Jestを使った依存性注入のテストは、モックを活用することで依存関係を制御しながら、確実なユニットテストを実行することができます。

モックオブジェクトの作成と使用例

モックオブジェクトは、依存性注入（DI）を利用したテストで重要な役割を果たします。モックはテストの際に外部リソースへのアクセスを不要にし、テスト対象となるコードの動作を独立して確認することを可能にします。ここでは、TypeScriptでの具体的なモックオブジェクトの作成方法と、それを使ったテストの実例を紹介します。

モックオブジェクトの作成

モックオブジェクトは、依存するサービスやモジュールを模倣して動作するダミーオブジェクトです。Jestを使って簡単にモックオブジェクトを作成できます。以下の例では、UserServiceをモックとして作成します。

// 依存するUserServiceのインターフェース
interface UserService {
  getUser(id: number): Promise<User>;
}

// UserServiceのモックオブジェクト
const mockUserService: UserService = {
  getUser: jest.fn().mockResolvedValue({ id: 1, name: 'Mock User' })
};

このモックでは、getUserメソッドが呼び出されるたびに、{ id: 1, name: 'Mock User' }というデータが返されるように設定されています。このようにして、実際のサービスを使わずにテスト用の挙動を定義できます。

モックオブジェクトを使ったテスト

次に、モックオブジェクトを使ったテストの実例を示します。ここでは、UserControllerがUserServiceに依存しており、その依存関係をモックに置き換えてテストを実行します。

class UserController {
  constructor(private userService: UserService) {}

  async getUserData(id: number) {
    const user = await this.userService.getUser(id);
    return user;
  }
}

// テストケース
describe('UserController', () => {
  let userController: UserController;

  beforeEach(() => {
    // モックされたUserServiceを注入
    userController = new UserController(mockUserService);
  });

  it('should return mocked user data', async () => {
    const result = await userController.getUserData(1);
    // 期待される結果と比較
    expect(result).toEqual({ id: 1, name: 'Mock User' });
    // モックメソッドが呼ばれたことを確認
    expect(mockUserService.getUser).toHaveBeenCalledWith(1);
  });
});

実際のテストの挙動

このテストでは、以下のことが行われています：

1. UserServiceがモックオブジェクトに置き換えられているため、getUserメソッドは実際にはモックから返されるデータを返します。
2. UserController.getUserDataメソッドが正しく動作するかどうかを確認するため、モックされたデータに基づいて期待される結果と比較しています。
3. getUserが正しい引数で呼び出されたかを確認しています（toHaveBeenCalledWith(1)）。

モックオブジェクトの利点

モックオブジェクトを使用することで、以下の利点があります：

• 外部リソースへの依存を排除：APIやデータベースなどの外部システムにアクセスすることなく、テストを独立して実行できます。
• テストの再現性：同じモックデータを何度も再現できるため、テスト結果が一貫します。
• エラーハンドリングのテスト：モックをカスタマイズして、例外やエラーハンドリングのシナリオを簡単に再現できます。

このように、モックオブジェクトを使うことで、依存性注入を活用したテストは簡潔で効率的に行うことが可能です。

依存性注入を使ったテストのベストプラクティス

依存性注入（DI）を使用したテストを効果的に行うには、いくつかのベストプラクティスを押さえておくことが重要です。これにより、テストの保守性や信頼性が向上し、将来的なコード変更にも強い設計が可能となります。ここでは、DIを使ったテストで覚えておくべきベストプラクティスを紹介します。

1. テストの独立性を保つ

テストは、他のテストや外部システムに依存しない形で実行できるように設計する必要があります。依存性注入を利用することで、テストの対象となるオブジェクト（SUT: System Under Test）が依存している他のコンポーネントをモック化し、テストの独立性を確保することができます。

const mockService = {
  getUser: jest.fn().mockResolvedValue({ id: 1, name: 'Mock User' })
};

// モックされた依存オブジェクトを注入してテスト
const controller = new UserController(mockService);

2. モックの挙動を適切に制御する

モックオブジェクトを使う際には、その挙動をテストシナリオごとに調整することが重要です。テスト対象の動作や例外処理を確認するために、モックが返す値やエラーメッセージを適切に設定しましょう。

// 成功ケース
mockService.getUser.mockResolvedValue({ id: 1, name: 'Success User' });

// エラーハンドリングのテスト
mockService.getUser.mockRejectedValue(new Error('User not found'));

3. テストのスコープを明確にする

依存性注入を使ったテストでは、どこまでをテスト対象とするのかスコープを明確にすることが大切です。モックを使うことで、テスト対象のクラスやメソッドの動作だけに焦点を当てることができます。

• ユニットテストでは、単一のメソッドやクラスの動作をテストします。
• 統合テストでは、複数のクラスやモジュールがどのように連携するかを検証します。

テストスコープが明確でない場合、無駄な依存関係の検証や外部システムへの依存が発生し、テストの保守性が低下します。

4. テストデータを再利用しない

テストごとに異なるデータやモックを使用することで、テストの信頼性が向上します。1つのテストケースが他のテストに影響を与えないように、モックデータやテスト環境はリセットするのが望ましいです。Jestでは、beforeEachやafterEachを使って環境を初期化できます。

beforeEach(() => {
  mockService.getUser.mockClear();
});

5. モックと実装の差異に注意する

モックは実際の動作を模倣しますが、実際の依存オブジェクトとは異なる挙動を示すこともあります。そのため、モックでのテストに合格しても、実際のシステムで動作しない可能性があることに注意し、重要なケースについては統合テストも併せて実施することが推奨されます。

6. 依存性を最小限にする

テストで使用するモックや依存性を最小限に抑えることで、テストの読みやすさと保守性が向上します。依存性が多すぎる場合、テストが複雑になり、モックの管理が難しくなります。可能な限り、依存性を減らし、単純なテストケースを作成することがベストプラクティスです。

7. 実際のデータとモックデータのバランスを取る

全てのテストでモックを使用するのではなく、場合によっては実際のデータやサービスを使う統合テストも実施しましょう。モックでは検出できない問題が、実際の依存関係とのやり取りで浮かび上がることがあります。

依存性注入を活用したテストでは、これらのベストプラクティスを守ることで、効果的かつ信頼性の高いテストを実行することが可能になります。

モックとスタブの違い

テストにおいて、モックとスタブはよく混同される概念ですが、異なる目的を持つテスト手法です。両者は依存オブジェクトの代わりに使われ、外部リソースへの依存を排除する点では共通していますが、それぞれの使い方や役割に違いがあります。ここでは、モックとスタブの違いを明確にし、それぞれの用途について説明します。

モックとは

モックは、テスト対象のオブジェクトが外部依存性に対してどのように振る舞うかを検証するために使用されます。モックは、メソッドの呼び出し回数や引数など、依存オブジェクトとのやり取りそのものを確認する目的で利用されます。モックは非常に柔軟で、呼び出し時に期待される振る舞いを模倣し、結果やエラーハンドリングのシナリオも細かく制御できます。

const mockService = {
  getUser: jest.fn().mockResolvedValue({ id: 1, name: 'Mock User' })
};

// テストケース
expect(mockService.getUser).toHaveBeenCalledWith(1);
expect(mockService.getUser).toHaveBeenCalledTimes(1);

モックは主に「テスト対象が正しい依存関係とのインタラクションをしているか」を検証するために使用されます。

スタブとは

スタブは、テスト対象が依存する外部オブジェクトを置き換えるために使用され、主に「結果の固定化」を目的としています。スタブは事前に決めたデータを返すため、テストが依存オブジェクトに依存せずに動作を確認できるようにします。ただし、モックほど細かく呼び出しや引数を検証することはできません。

const stubService = {
  getUser: () => ({ id: 1, name: 'Stub User' })
};

// テストケース
const result = stubService.getUser();
expect(result).toEqual({ id: 1, name: 'Stub User' });

スタブは「特定の入力に対して決まった結果を返す」ため、主にその依存オブジェクトの動作に依存せず、テスト対象のロジックを検証したい場合に使われます。

モックとスタブの違い

モックとスタブの主な違いは以下の通りです：

• 目的：
• モック：依存オブジェクトとのインタラクションを検証するために使用される。
• スタブ：特定の入力に対して決まった出力を返し、結果を固定化するために使用される。
• 挙動：
• モック：呼び出し回数や引数、例外のシミュレーションなどを柔軟に制御できる。
• スタブ：固定された値を返すが、呼び出し回数や引数の検証は行わない。
• 検証の焦点：
• モック：テスト対象が依存オブジェクトに対して正しいメソッドを呼び出しているか、正しい引数で呼ばれているかを検証する。
• スタブ：依存オブジェクトから返されるデータに基づいて、テスト対象のロジックが正しく動作しているかを確認する。

使用する場面の違い

• モックを使う場面：外部依存性とのやり取りを検証したいとき。例えば、外部APIへの呼び出しが適切に行われているか、何回呼ばれたか、正しい引数が渡されているかなどを確認する場合に使います。
• スタブを使う場面：テスト対象のビジネスロジックを確認したいとき。外部依存性からの返り値が決まっており、テスト対象がその結果に対してどのように動作するかを検証したい場合に使います。

これらの違いを理解し、テストの目的に応じてモックとスタブを使い分けることが、依存性注入を活用したテストの成功の鍵となります。

依存性注入とモックの課題

依存性注入（DI）とモックを使用したテストには多くの利点がありますが、それに伴ういくつかの課題も存在します。これらの課題を理解し、適切な対策を取ることで、DIやモックをより効果的に活用することができます。ここでは、DIやモックに関する代表的な課題とその解決策を紹介します。

1. モックと実際の実装の乖離

モックを使用する最大の課題の1つは、モックの挙動が実際の依存オブジェクトの動作と異なる場合です。モックはテストのためにカスタマイズされており、実際の依存性とは異なる振る舞いをする可能性があります。これにより、テストには合格しても実際のシステムでは問題が発生するリスクがあります。

解決策

• 統合テストを併用する：モックによるユニットテストだけでなく、実際の依存オブジェクトと連携した統合テストも実施し、モックでは見逃される可能性がある問題を発見します。
• モックと実装のメンテナンス：依存するサービスやライブラリの変更があった場合、モックもその変更に基づいて適切に更新することが重要です。

2. 過剰なモックの使用

モックは便利ですが、あまりにも多くの依存オブジェクトをモック化すると、テストのメンテナンスが困難になることがあります。特に複数のモックを扱う場合、それらのモックが正しく設定されているかを追跡するのが難しくなり、テストの複雑さが増す可能性があります。

解決策

• モックを最小限に留める：モックはテストの範囲を制御するために使用しますが、モック化する依存オブジェクトは本当に必要なものだけに絞ります。テストの目的に応じて、モック、スタブ、スパイなど適切なツールを使い分けます。
• 依存性の分離：クラスやモジュールが過剰な依存性を持っている場合、リファクタリングを検討し、依存性の分離を図ることも有効です。

3. 依存性注入の管理が複雑になる

DIを使用することでテスト可能な設計が実現しますが、大規模なプロジェクトでは、依存関係の管理が複雑化することがあります。多くのサービスやオブジェクトが注入されると、設定や依存の追跡が難しくなり、テストやデバッグが困難になります。

解決策

• DIコンテナの使用：依存性の管理にはDIコンテナを使用して、依存関係を一元的に管理します。これにより、依存性の解決とテスト用のモックオブジェクトの挿入が自動化され、コードの複雑さを軽減できます。
• 小さなモジュールに分割：依存関係が増えてきたら、クラスやモジュールを小さく保つことを心がけ、各コンポーネントが単一の責任を持つように設計します。

4. 過度なテスト依存

モックを使用する際、モックに依存しすぎると、テストがあまり現実的でないものになりがちです。これは特に、外部システムやAPIとの実際のやり取りがテストされない場合に問題となり、モックに基づいたテスト結果が実際の動作を保証しないことがあります。

解決策

• 実際の依存性を使ったテストの併用：すべてのテストをモックに頼らず、実際のサービスやリソースと連携するテストも適宜実施します。これにより、モックでは見つからない問題が検出されることがあります。
• クリティカルなパスの確認：特にビジネスロジックやクリティカルなシステムの部分については、モックに頼りすぎず、実際の環境を考慮したテストを行います。

5. モックの過剰なカスタマイズ

モックを多機能にしすぎると、テストコードが複雑化し、本来のテストの目的が失われることがあります。例えば、すべての依存オブジェクトに対してモックの挙動を詳細に設定すると、テスト自体が複雑になり、管理が難しくなります。

解決策

• シンプルなモックの設計：モックはできるだけシンプルに保ち、必要最低限の動作を模倣するだけにとどめます。過度に複雑なモックを避け、シンプルなテストケースを構築します。
• 共通のモックパターンを再利用：複数のテストで使用する共通のモックパターンは、テストヘルパーやユーティリティ関数としてまとめて管理することで、コードの重複を避けます。

依存性注入とモックはテストを容易にする強力なツールですが、その利点を最大限に活かすためには、これらの課題に注意しながら適切に設計・管理することが重要です。

依存性注入テストの応用例

依存性注入（DI）を使ったテストは、シンプルなユニットテストに留まらず、複雑なシステムにも応用することが可能です。特に、複数の依存オブジェクトを持つコンポーネントや、外部API、データベース、認証サービスなどと連携するシステムに対しても、DIを用いることで柔軟かつ効果的なテストを行うことができます。ここでは、実際のプロジェクトで役立ついくつかの応用例を紹介します。

1. 複数の依存オブジェクトを扱うケース

大規模なアプリケーションでは、1つのクラスが複数のサービスやリポジトリに依存する場合があります。この場合、DIを利用して複数の依存オブジェクトをモックに置き換え、各依存オブジェクトが正しく動作するかをテストします。

class OrderService {
  constructor(
    private paymentService: PaymentService,
    private inventoryService: InventoryService
  ) {}

  async processOrder(orderId: number) {
    const paymentResult = await this.paymentService.processPayment(orderId);
    const inventoryResult = await this.inventoryService.updateInventory(orderId);
    return paymentResult && inventoryResult;
  }
}

// テスト用モックの作成
const mockPaymentService = {
  processPayment: jest.fn().mockResolvedValue(true),
};
const mockInventoryService = {
  updateInventory: jest.fn().mockResolvedValue(true),
};

// テスト実行
describe('OrderService', () => {
  let orderService: OrderService;

  beforeEach(() => {
    orderService = new OrderService(mockPaymentService, mockInventoryService);
  });

  it('should process order successfully', async () => {
    const result = await orderService.processOrder(1);
    expect(result).toBe(true);
    expect(mockPaymentService.processPayment).toHaveBeenCalledWith(1);
    expect(mockInventoryService.updateInventory).toHaveBeenCalledWith(1);
  });
});

この例では、OrderServiceが複数の依存オブジェクトを持っており、それぞれをモックに置き換えてテストを行っています。各依存オブジェクトが正しいメソッドを呼び出していることを確認しつつ、processOrderのロジックを検証しています。

2. 外部APIとの連携

外部APIとの通信を行うサービスをテストする際、実際のAPIに依存することは避けたいケースが多いです。そこで、API呼び出しをモックに置き換え、APIからのレスポンスやエラーハンドリングをシミュレーションします。

class ApiService {
  constructor(private httpClient: HttpClient) {}

  async fetchData(url: string): Promise<Data> {
    const response = await this.httpClient.get(url);
    return response.data;
  }
}

// テスト用モック
const mockHttpClient = {
  get: jest.fn().mockResolvedValue({ data: { id: 1, name: 'Test Data' } }),
};

// テスト実行
describe('ApiService', () => {
  let apiService: ApiService;

  beforeEach(() => {
    apiService = new ApiService(mockHttpClient);
  });

  it('should return data from the API', async () => {
    const data = await apiService.fetchData('http://api.example.com/data');
    expect(data).toEqual({ id: 1, name: 'Test Data' });
    expect(mockHttpClient.get).toHaveBeenCalledWith('http://api.example.com/data');
  });
});

この例では、HttpClientをモック化し、APIからのレスポンスをシミュレーションしています。これにより、外部APIに依存せず、テストを実行できるようになっています。

3. 認証サービスのモック化

ユーザー認証を扱う場合、実際の認証システムに依存するとテストが難しくなることがあります。DIを使用して認証サービスをモック化し、さまざまな認証シナリオをテストすることが可能です。

class AuthService {
  constructor(private authProvider: AuthProvider) {}

  async login(username: string, password: string) {
    const token = await this.authProvider.authenticate(username, password);
    return token;
  }
}

// モック認証サービス
const mockAuthProvider = {
  authenticate: jest.fn().mockResolvedValue('mock-token'),
};

// テスト実行
describe('AuthService', () => {
  let authService: AuthService;

  beforeEach(() => {
    authService = new AuthService(mockAuthProvider);
  });

  it('should return token on successful login', async () => {
    const token = await authService.login('user', 'pass');
    expect(token).toBe('mock-token');
    expect(mockAuthProvider.authenticate).toHaveBeenCalledWith('user', 'pass');
  });
});

この例では、AuthProviderをモック化することで、認証プロセスをテストしています。モックを使うことで、ユーザー認証に関わる外部依存を排除し、テストのスコープをコントロールしています。

4. エラーハンドリングのテスト

モックを使用することで、外部サービスが失敗するシナリオを簡単にシミュレーションし、エラーハンドリングのテストを行うことができます。

mockPaymentService.processPayment.mockRejectedValue(new Error('Payment failed'));

it('should handle payment failure', async () => {
  await expect(orderService.processOrder(1)).rejects.toThrow('Payment failed');
  expect(mockPaymentService.processPayment).toHaveBeenCalledWith(1);
});

この例では、processPaymentが失敗した場合のエラーハンドリングをテストしています。モックにエラーを返させることで、例外処理のロジックを確実に検証できます。

まとめ

依存性注入を活用したテストは、複数の依存関係を持つ複雑なシステムでも柔軟に対応できます。モックを効果的に活用することで、外部リソースへの依存を排除し、さまざまなシナリオやエラーケースをシミュレーションしながら、信頼性の高いテストを実現できます。

まとめ

本記事では、TypeScriptでの依存性注入（DI）を活用したテスト方法とモックの使用について解説しました。DIにより、クラス間の依存関係を明確に管理し、テストを効率的に行うことが可能です。モックを利用することで、外部リソースに依存せず、柔軟で再現性の高いテストを実行できます。モックとスタブの違いや、複数の依存オブジェクトを持つケース、外部APIや認証サービスのテスト方法、さらにはエラーハンドリングのシナリオまで、幅広いテストの応用例を紹介しました。