什么是 ‘Dependency Injection’ (DI) 在 React 中的变体：如何在单元测试中轻松 Mock 深层组件？

依赖注入 (DI) 在 React 中的变体：如何在单元测试中轻松 Mock 深层组件

欢迎来到今天的讲座，我们将深入探讨一个在现代前端开发中至关重要的话题：依赖注入 (Dependency Injection, DI)。特别地，我们将聚焦于 DI 在 React 应用中的一种“变体”实现，以及这种模式如何彻底改变我们对深层组件进行单元测试的方式，使其变得前所未有的简单和高效。

1. 依赖注入 (DI) 的核心概念

在深入 React 的具体实践之前，我们必须先理解依赖注入这一核心软件设计原则。DI 是控制反转 (Inversion of Control, IoC) 原则的一种具体实现。

1.1 什么是依赖？

在软件开发中，一个组件或模块通常需要其他组件或模块才能完成其功能。这些被需要的组件或模块就是它的“依赖”。

示例：

• 一个 UserService 可能依赖于一个 HttpClient 来发起网络请求。
• 一个 ProductListComponent 可能依赖于一个 ProductService 来获取产品数据。
• 一个 Logger 模块可能依赖于一个 ConsoleAdapter 或 AnalyticsAdapter 来输出日志。

如果没有 DI，组件通常会自己创建或查找这些依赖。这会导致组件与它的依赖之间形成紧密的耦合。

1.2 什么是注入？

“注入”是指将一个组件所依赖的另一个组件（即依赖）提供给它，而不是让组件自己去创建或查找。这个过程通常由外部实体（如 DI 容器或手动配置）完成。

通过注入，组件不再负责创建或管理它的依赖，而是被动地接收它们。这使得组件本身变得更加专注于自己的核心业务逻辑。

1.3 DI 的基本原则：控制反转 (IoC)

DI 是 IoC 的一种形式。IoC 的核心思想是，控制权从应用程序代码转移到框架或运行时环境。在 DI 中，组件不再控制它所依赖对象的创建和生命周期，这些控制权被“反转”给外部实体。

1.4 DI 的好处

采用 DI 模式能够带来诸多显著优势：

• 解耦 (Decoupling)：组件不再直接依赖于特定实现，而是依赖于抽象（接口）。这使得替换依赖的实现变得容易，而无需修改使用它的组件。
• 可测试性 (Testability)：这是我们今天讲座的重点！由于依赖可以被轻松替换，在单元测试中，我们可以用模拟 (Mock) 或存根 (Stub) 对象替换真实的依赖，从而隔离被测试组件，确保测试的独立性和稳定性。
• 可维护性 (Maintainability)：代码结构更清晰，依赖关系更透明。当需要修改某个依赖的实现时，影响范围更小。
• 可扩展性 (Extensibility)：可以轻松地引入新的依赖实现，或者为现有依赖提供不同的配置，以适应不同的环境或需求。
• 代码复用 (Code Reusability)：独立、解耦的组件更容易在不同的上下文和项目中复用。

1.5 DI 的三种主要类型

虽然 DI 容器在 Java (Spring) 或 .NET (Autofac) 等后端框架中更为常见，但理解这些类型有助于我们思考 React 中的实现：

• 构造函数注入 (Constructor Injection)：依赖通过组件的构造函数提供。
• 属性注入 (Property Injection)：依赖通过组件的公共属性或设置器方法提供。
• 方法注入 (Method Injection)：依赖通过组件的某个特定方法调用时提供。

在 React 的函数组件和 Hook 时代，我们通常会看到类似属性注入或更接近一种“上下文注入”的形式。

2. React 中的依赖与挑战

React 组件作为 UI 的基本构建块，同样也需要处理各种依赖。

2.1 React 组件的“依赖”

在 React 应用中，组件的依赖可以非常广泛：

• 数据服务：AuthService (认证), ProductService (产品数据), UserService (用户数据)。
• API 客户端：HttpClient (封装 fetch 或 axios)。
• 日志服务：Logger (用于错误报告或分析)。
• 实用工具：日期格式化、货币转换等。
• 第三方 SDK：分析工具、支付网关客户端等。
• 配置对象：API 密钥、环境变量等。

2.2 React 的组件树结构：深层组件的定义

React 应用通常由一个嵌套的组件树组成。一个“深层组件”指的是在组件树中距离根组件较远，需要通过多层父组件才能获取其所需依赖的组件。例如：App -> Layout -> Dashboard -> Widget -> ProductList -> ProductItem。这里的 ProductList 和 ProductItem 就可能是深层组件。

2.3 传统 React 依赖管理的问题

在没有明确 DI 策略的情况下，React 开发者通常会遇到以下问题：

• 属性钻取 (Prop Drilling)：

  • 当一个深层组件需要一个依赖时，如果该依赖是从组件树顶部提供的，那么它必须层层通过中间的父组件作为 props 传递下去，即使这些中间组件自身并不需要这个依赖。
  • 这使得代码变得冗长、难以阅读和维护。任何中间组件的 props 签名改变都可能影响到更深层的组件。

  // App.js
  function App() {
    const authService = new AuthService();
    return <Layout authService={authService} />;
  }
  
  // Layout.js
  function Layout({ authService }) {
    return <Header authService={authService}><Dashboard authService={authService} /></Header>;
  }
  
  // Dashboard.js
  function Dashboard({ authService }) {
    return <UserPanel authService={authService} />;
  }
  
  // UserPanel.js - 终于用到了！
  function UserPanel({ authService }) {
    // ... 使用 authService
  }

  这种方式在层级不多时尚可接受，但层级一深，就会成为噩梦。

• 全局单例模式 (Global Singleton)：

  • 开发者可能会创建全局的单例服务，并直接在组件中 import 它们。
  • services/auth.ts

    class AuthService {
      login() { /* ... */ }
      logout() { /* ... */ }
    }
    export const authService = new AuthService(); // 全局单例

  • components/UserPanel.tsx

    import { authService } from '../services/auth'; // 直接导入
    
    function UserPanel() {
      // ... 使用 authService
    }

  • 问题：难以测试。在单元测试中，如果一个测试文件 import 了 authService，并且你想要为这个测试提供一个 mock 版本，你需要使用 jest.mock('../services/auth')。
    • jest.mock 是全局性的：一旦 mock，所有导入该模块的测试都会受到影响，这可能导致测试之间的互相污染。
    • 难以针对不同的测试场景提供不同的 mock 实现。
    • 难以在运行时动态替换服务。

2.4 单元测试深层组件的困境

当我们需要对一个深层组件进行单元测试时，如果它依赖于通过上述传统方式获取的服务，测试会变得异常复杂：

• jest.mock 的局限性：

  • 如前所述，jest.mock 影响的是模块本身。如果你只想在 特定测试用例 中 mock 某个服务的行为，而其他测试用例需要真实的或者不同行为的 mock，jest.mock 很难做到。
  • 对于通过 prop drilling 传递的依赖，jest.mock 无能为力，因为你不能 mock 一个 prop。你必须渲染整个父组件链，并在顶部注入 mock，这使得单元测试更像集成测试。

• React Testing Library (RTL) 和 Enzyme 的不同策略：

  • RTL 鼓励全渲染 (full rendering)，模拟用户实际使用应用的方式。这意味着它会渲染组件树的尽可能多部分，包括其子组件。
  • Enzyme 提供了 shallow 渲染，只渲染组件本身而不渲染其子组件。但这也有局限性，例如它不会触发 useEffect，也不会正确处理 Context。
  • 无论哪种方式，如果一个深层组件的依赖是硬编码 import 或通过深层 prop drilling 传递的，测试时都面临挑战。你必须想办法在测试环境中替换这些依赖。

这就是为什么我们需要一种更优雅、更具控制力的 DI 变体。

3. React 中 ‘Dependency Injection’ 的变体：基于 Context 的显式注入

React 自身没有内置的 DI 容器或机制，但它提供了强大的工具，如 Context API，让我们能够模拟 DI 的效果。我们所说的“DI 变体”的核心思想就是：利用 React Context API 显式地将依赖（如服务实例）从组件树的顶层注入到深层组件，而不是通过 import 或 prop drilling。

3.1 核心思想

我们将创建一个专门的 React Context 来承载我们应用中的所有核心服务或依赖。然后，在应用根部或某个较高层级，使用一个 Provider 组件来提供这些服务的实际实例。深层组件通过 useContext Hook 来消费这些服务。

3.2 为什么是“变体”？

它之所以是“变体”，是因为我们不是在使用一个成熟的 DI 框架，而是利用 React 自身的机制来实现 DI 的核心目标：解耦和可测试性。我们并没有一个会自动发现和注入依赖的容器，而是需要手动设置 Context Provider。

3.3 目标

这种模式的首要目标是：在单元测试中，能够轻松地替换（mock）这些注入的依赖。 我们可以通过在测试中渲染组件时，用一个临时的 Provider 组件包裹它，并向该 Provider 传递我们定制的 mock 服务实例，从而实现依赖的隔离和替换。

4. 实现方式一：基于 React Context 和 Custom Hook

现在，让我们通过具体的代码示例来构建这种 DI 变体。

4.1 步骤 1：定义依赖接口 (TypeScript 推荐)

使用 TypeScript 来定义服务接口是最佳实践，它能提供类型安全，并清晰地说明每个服务提供了哪些功能。

// src/services/interfaces.ts

// 认证服务接口
export interface IAuthService {
  login(credentials: { username: string; password: string }): Promise<boolean>;
  logout(): void;
  isAuthenticated(): boolean;
  getUserInfo(): { id: string; name: string } | null;
}

// 产品服务接口
export interface IProductService {
  getProducts(): Promise<Product[]>;
  getProductById(id: string): Promise<Product | undefined>;
  createProduct(product: Omit<Product, 'id'>): Promise<Product>;
  updateProduct(id: string, product: Partial<Product>): Promise<Product>;
  deleteProduct(id: string): Promise<void>;
}

// 日志服务接口
export interface ILogger {
  info(message: string, ...args: any[]): void;
  warn(message: string, ...args: any[]): void;
  error(message: string, error?: Error, ...args: any[]): void;
}

// 定义产品数据结构
export interface Product {
  id: string;
  name: string;
  price: number;
  description: string;
}

// 所有依赖服务的集合接口
export interface IServices {
  authService: IAuthService;
  productService: IProductService;
  logger: ILogger;
  // ... 其他服务
}

4.2 步骤 2：创建依赖的实际实现

接下来，我们为这些接口创建具体的实现。

// src/services/AuthService.ts
import { IAuthService } from './interfaces';

class AuthService implements IAuthService {
  private authenticated = false;
  private userInfo: { id: string; name: string } | null = null;

  async login(credentials: { username: string; password: string }): Promise<boolean> {
    console.log(`Attempting to log in user: ${credentials.username}`);
    // 模拟 API 调用
    return new Promise((resolve) => {
      setTimeout(() => {
        if (credentials.username === 'test' && credentials.password === 'password') {
          this.authenticated = true;
          this.userInfo = { id: 'user-123', name: 'Test User' };
          console.log('Login successful');
          resolve(true);
        } else {
          this.authenticated = false;
          this.userInfo = null;
          console.log('Login failed');
          resolve(false);
        }
      }, 500);
    });
  }

  logout(): void {
    console.log('Logging out');
    this.authenticated = false;
    this.userInfo = null;
  }

  isAuthenticated(): boolean {
    return this.authenticated;
  }

  getUserInfo(): { id: string; name: string } | null {
    return this.userInfo;
  }
}

export default AuthService; // 导出类，而不是实例

// src/services/ProductService.ts
import { IProductService, Product } from './interfaces';

class ProductService implements IProductService {
  private products: Product[] = [
    { id: 'p1', name: 'Laptop Pro', price: 1200, description: 'High-performance laptop.' },
    { id: 'p2', name: 'Mechanical Keyboard', price: 150, description: 'Tactile and responsive.' },
    { id: 'p3', name: 'Wireless Mouse', price: 75, description: 'Ergonomic and precise.' },
  ];

  async getProducts(): Promise<Product[]> {
    console.log('Fetching all products');
    return new Promise((resolve) => {
      setTimeout(() => resolve([...this.products]), 300);
    });
  }

  async getProductById(id: string): Promise<Product | undefined> {
    console.log(`Fetching product by ID: ${id}`);
    return new Promise((resolve) => {
      setTimeout(() => resolve(this.products.find(p => p.id === id)), 200);
    });
  }

  async createProduct(product: Omit<Product, 'id'>): Promise<Product> {
    console.log('Creating new product', product);
    return new Promise((resolve) => {
      setTimeout(() => {
        const newProduct: Product = { ...product, id: `p${this.products.length + 1}` };
        this.products.push(newProduct);
        resolve(newProduct);
      }, 400);
    });
  }

  async updateProduct(id: string, product: Partial<Product>): Promise<Product> {
    console.log(`Updating product ID: ${id}`, product);
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        const index = this.products.findIndex(p => p.id === id);
        if (index > -1) {
          const updatedProduct = { ...this.products[index], ...product };
          this.products[index] = updatedProduct;
          resolve(updatedProduct);
        } else {
          reject(new Error('Product not found'));
        }
      }, 400);
    });
  }

  async deleteProduct(id: string): Promise<void> {
    console.log(`Deleting product ID: ${id}`);
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        const initialLength = this.products.length;
        this.products = this.products.filter(p => p.id !== id);
        if (this.products.length < initialLength) {
          resolve();
        } else {
          reject(new Error('Product not found'));
        }
      }, 300);
    });
  }
}

export default ProductService;

// src/services/Logger.ts
import { ILogger } from './interfaces';

class Logger implements ILogger {
  info(message: string, ...args: any[]): void {
    console.info(`[INFO] ${message}`, ...args);
  }

  warn(message: string, ...args: any[]): void {
    console.warn(`[WARN] ${message}`, ...args);
  }

  error(message: string, error?: Error, ...args: any[]): void {
    console.error(`[ERROR] ${message}`, error, ...args);
  }
}

export default Logger;

注意，我们导出的是类本身，而不是它们的实例。实例的创建将在 Provider 中完成。

4.3 步骤 3：创建依赖 Context

我们将创建一个 React Context 来存储所有服务的实例。为了避免在没有 Provider 的情况下出现运行时错误，我们必须为 createContext 提供一个默认值。这个默认值通常是一个“空”或“无效”的服务实现，或者抛出错误，以提示开发者忘记提供 Provider。

// src/contexts/DependencyContext.ts
import React, { createContext, useContext as useReactContext } from 'react';
import { IServices, IAuthService, IProductService, ILogger } from '../services/interfaces';

// 提供一个默认的，会抛出错误的实现，以防忘记包裹 Provider
const defaultServices: IServices = {
  authService: {
    login: () => { throw new Error('AuthService not provided'); },
    logout: () => { throw new Error('AuthService not provided'); },
    isAuthenticated: () => { throw new Error('AuthService not provided'); },
    getUserInfo: () => { throw new Error('AuthService not provided'); },
  },
  productService: {
    getProducts: () => { throw new Error('ProductService not provided'); },
    getProductById: () => { throw new Error('ProductService not provided'); },
    createProduct: () => { throw new Error('ProductService not provided'); },
    updateProduct: () => { throw new Error('ProductService not provided'); },
    deleteProduct: () => { throw new Error('ProductService not provided'); },
  },
  logger: {
    info: () => { throw new Error('Logger not provided'); },
    warn: () => { throw new Error('Logger not provided'); },
    error: () => { throw new Error('Logger not provided'); },
  },
};

export const DependencyContext = createContext<IServices>(defaultServices);

4.4 步骤 4：创建依赖 Provider 组件

DependencyProvider 组件负责实例化实际的服务，并通过 DependencyContext.Provider 将它们提供给组件树。

// src/contexts/DependencyProvider.tsx
import React, { FC, ReactNode, useMemo } from 'react';
import { DependencyContext } from './DependencyContext';
import { IServices } from '../services/interfaces';
import AuthService from '../services/AuthService';
import ProductService from '../services/ProductService';
import Logger from '../services/Logger';

interface DependencyProviderProps {
  children: ReactNode;
  // 允许在外部覆盖默认的服务实现，这在测试中非常有用
  services?: Partial<IServices>;
}

export const DependencyProvider: FC<DependencyProviderProps> = ({ children, services: overrideServices }) => {
  // 使用 useMemo 确保 services 对象在每次渲染时保持引用不变，
  // 除非其依赖发生变化，这对于性能优化至关重要，可以避免不必要的子组件重渲染。
  const services = useMemo(() => {
    // 实例化默认服务
    const defaultImplementations: IServices = {
      authService: new AuthService(),
      productService: new ProductService(),
      logger: new Logger(),
    };
    // 合并外部传入的覆盖服务
    return { ...defaultImplementations, ...overrideServices };
  }, [overrideServices]); // 只有当 overrideServices 变化时才重新计算

  return (
    <DependencyContext.Provider value={services}>
      {children}
    </DependencyContext.Provider>
  );
};

4.5 步骤 5：创建 Custom Hook 来消费依赖

为了方便组件消费依赖，我们封装一个自定义 Hook。它会从 DependencyContext 中获取服务，并提供一个更简洁的 API。

// src/hooks/useServices.ts
import { useContext as useReactContext } from 'react';
import { DependencyContext } from '../contexts/DependencyContext';
import { IAuthService, IProductService, ILogger } from '../services/interfaces';

// 这是一个通用的 Hook，用于获取所有服务
export const useServices = () => {
  const services = useReactContext(DependencyContext);
  return services;
};

// 也可以创建更细粒度的 Hook，如果某个组件只关心某个服务
export const useAuth = (): IAuthService => {
  const { authService } = useReactContext(DependencyContext);
  return authService;
};

export const useProducts = (): IProductService => {
  const { productService } = useReactContext(DependencyContext);
  return productService;
};

export const useLogger = (): ILogger => {
  const { logger } = useReactContext(DependencyContext);
  return logger;
};

4.6 代码示例：一个完整的服务注入流程

根组件 (App.tsx) 如何使用 DependencyProvider：

// src/App.tsx
import React from 'react';
import { DependencyProvider } from './contexts/DependencyProvider';
import DashboardPage from './pages/DashboardPage';

function App() {
  return (
    <DependencyProvider>
      <div className="App">
        <h1>My React App</h1>
        <DashboardPage />
      </div>
    </DependencyProvider>
  );
}

export default App;

深层组件 (ProductList.tsx, AuthButton.tsx) 如何消费依赖：

// src/components/AuthButton.tsx
import React from 'react';
import { useAuth, useLogger } from '../hooks/useServices';

function AuthButton() {
  const authService = useAuth();
  const logger = useLogger();
  const isAuthenticated = authService.isAuthenticated();
  const userInfo = authService.getUserInfo();

  const handleAuthClick = async () => {
    if (isAuthenticated) {
      authService.logout();
      logger.info('User logged out.');
    } else {
      const success = await authService.login({ username: 'test', password: 'password' });
      if (success) {
        logger.info('User logged in successfully.');
      } else {
        logger.warn('Login failed.');
      }
    }
  };

  return (
    <div>
      {isAuthenticated ? (
        <span>Welcome, {userInfo?.name}! </span>
      ) : (
        <span>Please log in. </span>
      )}
      <button onClick={handleAuthClick}>
        {isAuthenticated ? 'Logout' : 'Login'}
      </button>
    </div>
  );
}

export default AuthButton;

// src/components/ProductList.tsx
import React, { useEffect, useState } from 'react';
import { useProducts, useLogger } from '../hooks/useServices';
import { Product } from '../services/interfaces';

function ProductList() {
  const productService = useProducts();
  const logger = useLogger();
  const [products, setProducts] = useState<Product[]>([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    const fetchProducts = async () => {
      try {
        setLoading(true);
        const fetchedProducts = await productService.getProducts();
        setProducts(fetchedProducts);
        logger.info('Products fetched successfully.');
      } catch (err: any) {
        setError(err.message || 'Failed to fetch products');
        logger.error('Failed to fetch products', err);
      } finally {
        setLoading(false);
      }
    };
    fetchProducts();
  }, [productService, logger]);

  if (loading) {
    return <div>Loading products...</div>;
  }

  if (error) {
    return <div style={{ color: 'red' }}>Error: {error}</div>;
  }

  return (
    <div>
      <h2>Product List</h2>
      {products.length === 0 ? (
        <p>No products available.</p>
      ) : (
        <ul>
          {products.map((product) => (
            <li key={product.id}>
              {product.name} - ${product.price.toFixed(2)}
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

export default ProductList;

// src/pages/DashboardPage.tsx
import React from 'react';
import AuthButton from '../components/AuthButton';
import ProductList from '../components/ProductList';

function DashboardPage() {
  return (
    <div>
      <h1>Dashboard</h1>
      <AuthButton />
      <hr />
      <ProductList />
    </div>
  );
}

export default DashboardPage;

现在，AuthButton 和 ProductList 都是深层组件（相对于 App），它们不再通过 props 接收服务，也不直接 import 全局单例。它们通过 useAuth, useProducts, useLogger 等 Hook 声明式地获取所需服务。

5. 单元测试中的 Mocking 魔法

现在到了最激动人心的部分：这种 DI 变体如何简化单元测试中的 Mocking。

5.1 核心优势

在单元测试中，我们可以通过提供一个带有 mock 依赖的 DependencyProvider 来包裹被测试组件。由于 DependencyProvider 接受一个 services prop 用于覆盖默认实现，我们可以在测试中轻松地替换任何服务。

5.2 场景 1：测试消费依赖的深层组件

让我们以 ProductList 组件为例。它依赖于 ProductService 来获取产品数据，以及 Logger 来记录日志。在测试中，我们不希望真正调用 API，也不希望在控制台打印真实日志。

// src/components/ProductList.test.tsx
import React from 'react';
import { render, screen, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import ProductList from './ProductList';
import { DependencyProvider } from '../contexts/DependencyProvider';
import { IProductService, ILogger, Product } from '../services/interfaces';

describe('ProductList', () => {
  let mockProductService: jest.Mocked<IProductService>;
  let mockLogger: jest.Mocked<ILogger>;

  beforeEach(() => {
    // 为每次测试创建一个新的 mock 实例，确保测试隔离
    mockProductService = {
      getProducts: jest.fn(),
      getProductById: jest.fn(),
      createProduct: jest.fn(),
      updateProduct: jest.fn(),
      deleteProduct: jest.fn(),
    };
    mockLogger = {
      info: jest.fn(),
      warn: jest.fn(),
      error: jest.fn(),
    };
  });

  // 辅助渲染函数，用于包裹 DependencyProvider 并注入 mock 服务
  const renderWithMocks = (component: React.ReactElement) => {
    return render(
      <DependencyProvider services={{ productService: mockProductService, logger: mockLogger }}>
        {component}
      </DependencyProvider>
    );
  };

  test('应该在加载时显示加载状态，然后显示产品列表', async () => {
    const mockProducts: Product[] = [
      { id: 'p1', name: 'Mock Laptop', price: 1000, description: 'A mock laptop.' },
      { id: 'p2', name: 'Mock Mouse', price: 50, description: 'A mock mouse.' },
    ];
    mockProductService.getProducts.mockResolvedValue(mockProducts); // Mock getProducts 的返回值

    renderWithMocks(<ProductList />);

    // 初始状态应该显示加载中
    expect(screen.getByText(/Loading products.../i)).toBeInTheDocument();

    // 等待产品加载完成
    await waitFor(() => {
      expect(screen.queryByText(/Loading products.../i)).not.toBeInTheDocument();
      expect(screen.getByText('Mock Laptop - $1000.00')).toBeInTheDocument();
      expect(screen.getByText('Mock Mouse - $50.00')).toBeInTheDocument();
    });

    // 验证 logger.info 是否被调用
    expect(mockLogger.info).toHaveBeenCalledWith('Products fetched successfully.');
  });

  test('应该在产品获取失败时显示错误信息', async () => {
    const errorMessage = 'Network error during product fetch.';
    mockProductService.getProducts.mockRejectedValue(new Error(errorMessage)); // Mock 失败情况

    renderWithMocks(<ProductList />);

    await waitFor(() => {
      expect(screen.getByText(`Error: ${errorMessage}`)).toBeInTheDocument();
    });

    // 验证 logger.error 是否被调用
    expect(mockLogger.error).toHaveBeenCalledWith('Failed to fetch products', expect.any(Error));
  });

  test('当没有产品时显示无产品信息', async () => {
    mockProductService.getProducts.mockResolvedValue([]); // Mock 空产品列表

    renderWithMocks(<ProductList />);

    await waitFor(() => {
      expect(screen.getByText(/No products available./i)).toBeInTheDocument();
    });
  });
});

分析上述测试：

1. 无需 jest.mock 全局模块：我们没有在文件顶部使用 jest.mock('../services/ProductService')。这意味着我们没有全局地替换真实的服务实现。
2. 细粒度控制：我们为每个测试创建了独立的 mockProductService 和 mockLogger 实例，并在 beforeEach 中确保它们是全新的。这保证了测试之间的隔离。
3. 轻松注入：通过 DependencyProvider services={{ productService: mockProductService, logger: mockLogger }}，我们直接将 mock 实例注入到了被测试组件的上下文中。
4. 清晰的断言：我们可以轻松地断言 mock 服务的方法是否被调用，以及它们的调用参数。
5. Focus on Component Logic：测试专注于 ProductList 组件自身的渲染逻辑和与服务的交互，而不是服务的内部实现。

5.3 场景 2：测试需要不同依赖行为的多个组件

如果我们在同一个测试文件中需要测试 AuthButton 和 ProductList，并且它们需要不同的 AuthService 或 ProductService 行为，这种模式也能轻松应对。

// src/components/AuthButton.test.tsx
import React from 'react';
import { render, screen, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import AuthButton from './AuthButton';
import { DependencyProvider } from '../contexts/DependencyProvider';
import { IAuthService, ILogger } from '../services/interfaces';

describe('AuthButton', () => {
  let mockAuthService: jest.Mocked<IAuthService>;
  let mockLogger: jest.Mocked<ILogger>;

  beforeEach(() => {
    mockAuthService = {
      login: jest.fn(),
      logout: jest.fn(),
      isAuthenticated: jest.fn(),
      getUserInfo: jest.fn(),
    };
    mockLogger = {
      info: jest.fn(),
      warn: jest.fn(),
      error: jest.fn(),
    };
  });

  const renderWithMocks = (component: React.ReactElement) => {
    return render(
      <DependencyProvider services={{ authService: mockAuthService, logger: mockLogger }}>
        {component}
      </DependencyProvider>
    );
  };

  test('应该在未认证时显示 "Login" 按钮，点击后尝试登录', async () => {
    mockAuthService.isAuthenticated.mockReturnValue(false);
    mockAuthService.getUserInfo.mockReturnValue(null);
    mockAuthService.login.mockResolvedValue(true); // 登录成功

    renderWithMocks(<AuthButton />);

    expect(screen.getByText(/Please log in./i)).toBeInTheDocument();
    const loginButton = screen.getByRole('button', { name: /Login/i });
    expect(loginButton).toBeInTheDocument();

    await userEvent.click(loginButton);

    expect(mockAuthService.login).toHaveBeenCalledWith({ username: 'test', password: 'password' });
    expect(mockLogger.info).toHaveBeenCalledWith('User logged in successfully.');
  });

  test('应该在已认证时显示 "Logout" 按钮和用户信息，点击后尝试登出', async () => {
    mockAuthService.isAuthenticated.mockReturnValue(true);
    mockAuthService.getUserInfo.mockReturnValue({ id: 'u1', name: 'TestUser' });
    mockAuthService.logout.mockImplementation(() => {}); // 登出不需要返回值

    renderWithMocks(<AuthButton />);

    expect(screen.getByText(/Welcome, TestUser!/i)).toBeInTheDocument();
    const logoutButton = screen.getByRole('button', { name: /Logout/i });
    expect(logoutButton).toBeInTheDocument();

    await userEvent.click(logoutButton);

    expect(mockAuthService.logout).toHaveBeenCalledTimes(1);
    expect(mockLogger.info).toHaveBeenCalledWith('User logged out.');
  });
});

5.4 对比传统 jest.mock 的困难

特性/模式	传统 jest.mock (全局单例)	DI 变体 (Context + Provider)
Mock 范围	全局，影响所有导入该模块的测试文件。	局部，仅影响被 DependencyProvider 包裹的组件及其子组件。
灵活性	难以在同一个测试文件中针对不同测试用例提供不同 mock。	极易为每个测试用例提供独立的 mock 实例和行为。
依赖来源	只能 mock 通过 import 导入的模块。	可以 mock 任何通过 Context 注入的服务。
耦合性	组件与服务的具体实现通过 import 紧密耦合。	组件依赖于服务接口，通过 Context 解耦。
易用性	需要理解 jest.mock 的复杂行为和作用域。	简单地将 mock 实例作为 prop 传递给 Provider。
测试类型	更倾向于集成测试（因为 mock 影响大）。	真正的单元测试，隔离性强。

通过上面的对比，我们可以清楚地看到，DI 变体在单元测试的灵活性、隔离性和易用性方面具有压倒性优势。它提供的是“实例”级别的 mock，而不是“模块”级别的 mock，这在 React 组件测试中至关重要。

6. 高级主题与最佳实践

6.1 默认值与懒加载

• createContext 默认值的重要性：
  • 我们在 DependencyContext.ts 中提供了会抛出错误的默认实现。这是一种“防御性编程”，可以立即发现忘记包裹 DependencyProvider 的错误。
  • 另一种策略是提供一个“空操作”或“开发模式”的默认值，例如 logger.info = () => {}，但这可能会隐藏错误。通常，抛出错误更安全。
• 何时在 Provider 中实例化，何时在 Hook 中懒加载：
  • 在 DependencyProvider 中实例化服务是最常见的方式，因为服务通常是应用启动时就需要准备好的。
  • 如果某个服务初始化成本很高，且并非所有组件都会用到，可以考虑在 useServices Hook 内部，在第一次被调用时才懒加载。但这会增加 Hook 的复杂性，通常不推荐，除非有明确的性能需求。

6.2 管理大量依赖

随着应用增长，服务数量可能变得很多。

• 单一 DependencyContext vs. 多个专用 Context？

  • 单一 Context (我们示例中的 IServices 对象)：
    • 优点：统一管理，一个 DependencyProvider 即可提供所有服务，消费 Hook 简单 (useServices().authService)。
    • 缺点：如果 DependencyProvider 的 value 对象发生变化（即使只是其中一个服务实例发生变化），所有消费该 Context 的组件都会重新渲染。如果 useMemo 优化得当，这通常不是问题。
  • 多个专用 Context (例如 AuthContext, ProductContext)：
    • 优点：更细粒度的控制，只有当特定 Context 的 value 变化时，消费该 Context 的组件才会重渲染。
    • 缺点：增加了 Context 和 Provider 的数量，导致 App.tsx 中的 Provider 嵌套层级变深，消费 Hook 也可能更分散 (useAuth(), useProducts())。
  • 权衡：对于大多数应用，单一 Context 传递一个包含所有服务实例的对象，并配合 useMemo 优化，是一个很好的平衡点。只有当性能分析明确指出由于 Context 的频繁变化导致了不必要的重渲染时，才考虑拆分 Context。

• 使用 useMemo 优化 Provider 的 value：

  • 在 DependencyProvider 中，我们使用了 useMemo 来缓存 services 对象。这是至关重要的！
  • 如果 services 对象在每次渲染时都创建一个新引用，那么即使其内部的服务实例没有改变，DependencyContext.Provider 的 value 也被认为是不同的，这将导致所有消费 DependencyContext 的组件及其子组件不必要的重渲染。
  • useMemo 确保 services 对象只有在其依赖 (overrideServices) 发生变化时才重新创建，从而有效避免了性能问题。

6.3 工厂函数 (Factory Functions)

当依赖的创建需要运行时参数，或者初始化逻辑复杂到需要一个专门的工厂时，Provider 可以接收工厂函数而不是实例。

// src/contexts/DependencyProvider.tsx (修改示例)
interface DependencyProviderProps {
  children: ReactNode;
  // 允许传入工厂函数
  serviceFactories?: {
    authService?: () => IAuthService;
    productService?: () => IProductService;
    logger?: (appName: string) => ILogger; // 示例：logger 需要 appName
  };
}

export const DependencyProvider: FC<DependencyProviderProps> = ({ children, serviceFactories }) => {
  const services = useMemo(() => {
    const defaultImplementations: IServices = {
      authService: (serviceFactories?.authService || (() => new AuthService()))(),
      productService: (serviceFactories?.productService || (() => new ProductService()))(),
      logger: (serviceFactories?.logger || (() => new Logger()))('MyApp'), // 使用工厂函数创建
    };
    return defaultImplementations;
  }, [serviceFactories]); // 依赖于工厂函数引用

  return (
    <DependencyContext.Provider value={services}>
      {children}
    </DependencyContext.Provider>
  );
};

// 在测试中可以这样使用
render(
  <DependencyProvider serviceFactories={{
    logger: () => ({
      info: jest.fn(),
      warn: jest.fn(),
      error: jest.fn(),
    })
  }}>
    <MyComponent />
  </DependencyProvider>
);

这种方式在需要更多控制或参数化依赖创建时非常有用。

6.4 异步依赖初始化

如果某些服务需要异步初始化（例如从服务器获取配置），DependencyProvider 内部可以处理加载状态。

// src/contexts/DependencyProvider.tsx (异步初始化示例)
import React, { FC, ReactNode, useEffect, useState, useMemo } from 'react';
// ... 其他导入

export const DependencyProvider: FC<DependencyProviderProps> = ({ children, services: overrideServices }) => {
  const [initializedServices, setInitializedServices] = useState<IServices | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    const initialize = async () => {
      try {
        setLoading(true);
        // 模拟异步初始化，例如从配置文件或远程获取
        // const config = await fetch('/api/config').then(res => res.json());

        const defaultImplementations: IServices = {
          authService: new AuthService(),
          productService: new ProductService(),
          logger: new Logger(),
        };
        setInitializedServices({ ...defaultImplementations, ...overrideServices });
      } catch (err: any) {
        setError(err);
      } finally {
        setLoading(false);
      }
    };
    initialize();
  }, [overrideServices]);

  if (loading) {
    return <div>Loading application services...</div>;
  }

  if (error) {
    return <div style={{ color: 'red' }}>Error initializing services: {error.message}</div>;
  }

  // 确保 initializedServices 不为 null
  if (!initializedServices) {
    return null; // 或者可以抛出错误，表示不应该出现这种情况
  }

  return (
    <DependencyContext.Provider value={initializedServices}>
      {children}
    </DependencyContext.Provider>
  );
};

这种情况下，消费服务的组件需要处理 DependencyProvider 内部的加载状态，或者只在 initializedServices 准备好之后才渲染 children。

6.5 TypeScript 的强大支持

如我们所见，TypeScript 在整个过程中发挥了关键作用：

• 接口定义：强制服务实现遵循特定契约，提供类型安全。
• 自动补全和重构：IDE 可以根据接口提供方法名和参数的自动补全，极大地提升开发效率，并减少人为错误。
• 早期错误检测：在编译时捕获类型不匹配的错误，而不是在运行时。

6.6 何时不使用此模式

这种模式并非适用于所有情况：

• 简单组件：对于没有外部依赖的纯展示组件，或者只有非常简单、不需要 mock 的实用函数，直接导入即可。过度设计会增加不必要的复杂性。
• UI 组件库中的纯展示组件：它们通常只接收 props 并渲染 UI，不涉及业务逻辑或外部服务。
• 过于简单的实用函数：例如一个简单的数学计算函数，直接导入或作为局部函数即可。

6.7 与状态管理库的协同

DI 模式主要用于注入 服务 或 功能，而不是 应用状态。它与 Redux, Zustand, Recoil 等状态管理库是互补的。

• 一个服务 (例如 ProductService) 可能会与状态管理库交互，例如在获取产品后， dispatch 一个 action 来更新全局产品状态。
• 状态管理库本身也可能被视为一种“依赖”，可以通过 DI 模式注入到组件中。

7. 深入探讨：性能与可维护性考量

7.1 性能

• Context.Provider 的 value 变化会导致所有消费该 Context 的组件重新渲染：这是 React Context 的一个重要特性。如果 DependencyProvider 的 value 对象在每次父组件渲染时都创建一个新引用，那么即使 value 内部的数据没有逻辑上的变化，React 也会认为 value 变了，导致所有依赖该 Context 的组件（包括 children）重新渲染。
• 优化策略：
  • 使用 useMemo 确保 value 对象引用不变：这是我们在 DependencyProvider 中已经实施的优化。useMemo 会缓存 value 对象，只有当其依赖项数组中的值发生变化时才重新计算。在我们的例子中，依赖项是 overrideServices。
  • 避免在 value 中放置经常变化的局部状态：如果你的 services 对象内部包含会频繁变化的组件局部状态，那么 useMemo 可能也无法完全阻止重渲染。在这种情况下，考虑将频繁变化的状态与不常变化的服务分离到不同的 Context 中。
  • 将 value 分割成多个更小的 Context：如前所述，如果单一 Context 导致了严重的性能瓶颈（这在实际中不常见，除非 value 变化非常频繁且子组件渲染成本很高），可以考虑创建多个专用 Context。

7.2 可维护性

• 清晰的服务接口定义：TypeScript 的接口强制了服务的契约，使得开发者更容易理解每个服务的职责和使用方式。
• Provider 集中化依赖管理：所有的服务实例化和初始化逻辑都集中在 DependencyProvider 中，这使得依赖的管理、升级和替换变得更加容易。开发者无需在整个应用中搜索 new AuthService() 的位置。
• 测试的隔离性增强：由于测试可以轻松地 mock 依赖，每个组件的测试都更加独立和稳定，减少了测试之间的互相影响和副作用。当一个服务发生变化时，只需要修改其自身的测试和使用它的组件的测试（如果接口改变），而不需要修改其他无关组件的测试。

7.3 代码组织

良好的代码组织结构对于大型应用至关重要：

• 将所有服务接口定义在一个文件或一个 interfaces 目录中 (src/services/interfaces.ts)。
• 将服务实现放在 src/services 目录下。
• 将 Context、Provider、Hook 组织在独立的目录中，例如 src/contexts 或 src/di。
• 消费服务的组件应放在 src/components 或 src/pages 中。

src/
├── App.tsx
├── index.tsx
├── components/
│   ├── AuthButton.tsx
│   ├── ProductList.tsx
│   └── ...
├── contexts/
│   ├── DependencyContext.ts
│   └── DependencyProvider.tsx
├── hooks/
│   └── useServices.ts
├── pages/
│   └── DashboardPage.tsx
└── services/
    ├── interfaces.ts
    ├── AuthService.ts
    ├── ProductService.ts
    └── Logger.ts

这种结构清晰地分离了关注点，使得项目更易于理解和扩展。

8. 这种模式的名称与相关概念

虽然没有一个官方的“React DI 变体”名称，但其核心思想可以概括为“基于 Context 的服务注入 (Context-based Service Injection)”或“显式依赖传递 (Explicit Dependency Passing)”。

• 与服务定位器 (Service Locator) 模式的区别：

  • 依赖注入 (DI)：组件是被动接收依赖的。它不知道依赖是从哪里来的，也不需要知道如何获取依赖。组件只声明它需要什么。
  • 服务定位器 (Service Locator)：组件是主动请求依赖的。它知道一个“定位器”或“注册表”对象，并向其请求它需要的服务。

  • 示例 (服务定位器)：

    // locator.ts
    class ServiceLocator {
      private services: Map<string, any> = new Map();
      register<T>(name: string, service: T) { this.services.set(name, service); }
      get<T>(name: string): T { return this.services.get(name) as T; }
    }
    export const locator = new ServiceLocator();
    // 在 App 启动时注册
    locator.register('authService', new AuthService());
    
    // 在组件中消费
    // function MyComponent() {
    //   const authService = locator.get<IAuthService>('authService');
    // }

  • 为什么 DI 通常优于 Service Locator：
    • 更符合 IoC 原则：DI 将依赖管理完全从组件中解耦。
    • 可测试性更强：DI 模式下，组件的依赖通过 props 或 Context 显式传递，测试时替换这些依赖更加直接和透明。服务定位器模式虽然也能 mock，但组件内部对定位器的调用是隐式的，难以追踪。
    • 依赖透明性：DI 模式下，组件的依赖一目了然（通过 Hook 或 props），而在服务定位器模式下，你需要阅读组件代码才能知道它通过定位器请求了哪些服务。
    • 编译时检查：使用 TypeScript 和 DI 模式，如果忘记提供某个依赖，编译器就能发现。而服务定位器模式在运行时才可能发现（如果 get 返回 undefined）。

因此，我们今天探讨的这种基于 React Context 的 DI 变体，是更倾向于依赖注入原则的实现，因为它让组件能够被动地接收依赖，从而最大化地实现解耦和可测试性。

9. 结论

通过今天的讲座，我们深入探讨了依赖注入在 React 中的一种强大变体：基于 Context 和 Custom Hook 的显式服务注入。这种模式通过将服务从组件树的顶层注入到深层组件，彻底解决了传统依赖管理中的“属性钻取”和全局单例带来的测试难题。

其核心价值在于，它不仅显著提升了组件的解耦程度和代码的可维护性，更重要的是，它为单元测试带来了前所未有的便利。开发者可以轻松地为每个测试用例提供独立的 mock 服务实例，从而实现高度隔离和稳定的单元测试。这种模式是构建大型、可维护、易于测试的 React 应用的基石。