Angular HTTP测试必学：HttpClientTestingModule实战指南

1. 项目概述：为什么 Angular 的 HTTP 请求测试不能只靠 console.log

Angular 应用里，只要涉及和后端 API 打交道，几乎必然用到 HttpClient —— 它是 Angular 官方推荐、基于 RxJS 的现代化 HTTP 客户端，封装了 XMLHttpRequest 和 fetch 的底层细节，提供了拦截器、请求/响应转换、错误统一处理等一整套企业级能力。但问题来了：当你写完一个服务，比如 UserService 调用 /api/users 获取用户列表，你总不能每次跑单元测试都真连一次后端吧？网络延迟、环境依赖、数据不一致、并发冲突……这些都会让测试变得不可靠、不可重复、不可持续。我带过三个前端团队，新同学写的第一个“通过”的 HTTP 测试，八成是 console.log(res) 看一眼就提交了，结果上线后发现拦截器没生效、错误状态码被吞掉、请求头漏传了 Authorization —— 这些问题， 只有在隔离环境下对 HttpClient 行为做精确断言才能提前暴露 。

这就是 HttpClientTestingModule 存在的根本意义：它不是模拟（mock）某个函数，而是 完全替换掉 Angular 的真实 HTTP 模块 ，提供一个受控的、可编程的“假后端”。它配合 HttpTestingController ，让你能像指挥交通警察一样，精准控制每一条请求的发出、匹配、响应和验证。你不需要启动 Express 服务器，也不需要写 JSON Server 配置；你只需要告诉控制器：“接下来我要发一个 GET 请求到 /api/users ，请返回一个 200 状态和这个用户数组”，然后它就会在测试运行时拦截这个请求，并把你的预设响应原封不动地塞给订阅者。整个过程零网络、零副作用、毫秒级完成。而热搜词里反复出现的 angular,c# httpclient ，其实恰恰反向印证了这个问题的普遍性——C# 开发者用 HttpClient 做集成测试时也面临同样困境，只是 Angular 的 DI 和模块化机制让解决方案更优雅、更内聚。所以这篇内容，不是教你怎么“写个测试”，而是带你亲手搭建一套 可验证、可追溯、可维护的 HTTP 行为契约体系 。适合所有正在用 Angular 写业务逻辑、又不想被线上 500 错误半夜叫醒的中高级前端开发者。

2. 核心设计思路与模块选型逻辑

2.1 为什么必须用 HttpClientTestingModule，而不是手动 mock HttpClient？

很多初学者会尝试直接 jest.mock('@angular/common/http') 或者在 TestBed.configureTestingModule 里 provide: HttpClient, useValue: { get: jest.fn() } 。这看似简单，但很快就会踩进三个深坑：

第一， 破坏请求生命周期完整性 。真实 HttpClient 不仅执行请求，还触发拦截器链（如 AuthInterceptor 、 LoggingInterceptor ）、应用 HttpParams 编码规则、处理 observe: 'response' 的完整响应对象。手动 mock 只能覆盖 .get() 方法本身，拦截器根本不会运行， params: new HttpParams().set('page', '1') 会被忽略， headers.append('X-Trace-ID', uuid) 也压根不会出现在请求头里。我曾经帮一个金融项目排查过一个线上 bug：测试里 mock 的 get() 直接返回 { data: [] } ，但真实环境里 AuthInterceptor 因为 token 过期抛出了 HttpErrorResponse ，而业务代码没做 error instanceof HttpErrorResponse 判断，直接崩了。这种问题，手动 mock 根本测不出来。

第二， 无法验证请求是否被正确发出 。mock 方案只能验证“调用了一次 get”，但无法断言“这次 get 是发给了 /api/orders?status=shipped ，且带了 Authorization: Bearer xxx 头”。而 HttpTestingController 提供的 expectOne() 方法，会严格比对 URL、method、headers、body（如果是 POST），任何一项不匹配就报错。这相当于给每个 HTTP 请求签了一份“电子合同”，测试失败时你能立刻看到是哪条条款没履行。

第三， 无法检测“幽灵请求” 。真实业务中常有忘记 unsubscribe() 导致的内存泄漏，或者异步逻辑错误引发的重复请求。 HttpClientTestingModule 在 afterEach() 钩子中会自动调用 controller.verify() ，如果还有未被 expectOne() 或 match() 捕获的待处理请求，测试直接失败。这就像一个守门员，确保你发出的每一个球，都必须有明确的落点和结果，不能悬在半空。

所以， HttpClientTestingModule 不是“可选项”，而是 Angular 单元测试 HTTP 的 唯一官方支持路径 。它的设计哲学是“ 替换成可控的、行为确定的替代品，而非打补丁式覆盖 ”。

2.2 HttpClientTestingModule 与 HttpTestingController 的协作关系

可以把 HttpClientTestingModule 理解为一个“测试专用的 HTTP 模块工厂”，它内部注册了两个关键 Provider：

• HttpClient ：一个轻量级代理，所有请求都转发给 HttpTestingController
• HttpTestingController ：真正的“请求调度中心”，维护一个待处理请求队列（ this._requests: HttpRequest<any>[] ）

它们的关系不是父子，而是 委托+状态管理 。当你在测试中注入 HttpClient 并调用 get('/api/users') 时，实际发生的是：

1. HttpClient 将构造好的 HttpRequest 对象推入 HttpTestingController 的内部队列；
2. HttpClient 返回一个 Observable<HttpResponse> ，其订阅逻辑被重定向到等待 HttpTestingController 的响应；
3. 你在测试代码中调用 controller.expectOne('/api/users') ，控制器从队列中 精确匹配并移除 该请求；
4. 你调用 req.flush([{id: 1, name: 'Alice'}]) ，控制器将预设响应推送给 HttpClient 的 Observable，触发订阅者的 next() 回调。

这个流程的关键在于“ 匹配即消费 ”。 expectOne() 不是“查看”，而是“领取”。一旦你 expectOne() 了一个请求，它就从队列中消失了，后续再 expectOne() 同样的 URL 就会报错 Expected one request, but there were 0 . 这种设计强制你为每一个发出的请求编写对应的验证逻辑，杜绝了“只发不验”的测试盲区。

2.3 为什么不直接用 fetch-mock 或 nock？Angular 的模块化优势在哪？

有人会问：既然都是模拟 HTTP，为什么不用更通用的 fetch-mock ？答案很现实： Angular 的依赖注入（DI）系统让测试隔离更彻底、更无侵入 。 fetch-mock 是全局 monkey patch，它会污染 window.fetch ，影响同一测试套件里其他不相关模块（比如一个测试 ChartService 的组件，它可能内部用了 fetch 加载配置）。而 HttpClientTestingModule 的作用域严格限定在 TestBed 创建的测试模块内， TestBed.resetTestingModule() 之后，所有 mock 状态自动清空，下个测试用的是全新干净的实例。更重要的是，它天然兼容 Angular 的拦截器。你写一个 AuthInterceptor ，在 TestBed 里 providers: [AuthInterceptor, { provide: HTTP_INTERCEPTORS, useClass: AuthInterceptor, multi: true }] ，它就会在测试中和生产环境一样被调用。 fetch-mock 做不到这点，因为它根本不理解 Angular 的拦截器链。所以，选择 HttpClientTestingModule ，本质上是选择了 Angular 生态的“约定优于配置”红利 ——你不用自己造轮子去模拟拦截器、请求体序列化、响应类型推导，框架已经为你铺好了路。

3. 核心实操步骤与关键环节详解

3.1 最小可行测试环境搭建：从零开始配置 TestBed

我们以一个典型的 UserService 为例，它有一个 getUsers() 方法，返回 Observable<User[]> ：

// user.service.ts
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { User } from './user.model';

@Injectable({
  providedIn: 'root'
})
export class UserService {
  private readonly baseUrl = '/api/users';

  constructor(private http: HttpClient) {}

  getUsers(): Observable<User[]> {
    return this.http.get<User[]>(this.baseUrl);
  }
}

要为它写一个可靠的单元测试，第一步不是写 it() ，而是 构建一个能运行 HttpClient 的测试模块 。以下是必须的三步初始化：

第一步：导入 HttpClientTestingModule

// user.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { UserService } from './user.service';
import { User } from './user.model';

describe('UserService', () => {
  let service: UserService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    // 关键：导入 HttpClientTestingModule 替代真实 HttpClientModule
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule], // ← 这一行是基石
      providers: [UserService]
    });

    service = TestBed.inject(UserService);
    httpMock = TestBed.inject(HttpTestingController); // ← 获取控制器实例
  });
});

提示： imports: [HttpClientTestingModule] 必须放在 TestBed.configureTestingModule 的 imports 数组里，不能放在 providers 。因为 HttpClientTestingModule 是一个 NgModule，它内部定义了 HttpClient 和 HttpTestingController 的 Provider。如果放错位置， TestBed.inject(HttpClient) 会失败，报错 NullInjectorError: No provider for HttpClient! 。

第二步：清理残留请求（至关重要）

afterEach(() => {
  // 关键：验证所有请求是否都被处理，防止“幽灵请求”
  httpMock.verify();
});

httpMock.verify() 是一道安全阀。它检查 HttpTestingController 的内部请求队列是否为空。如果测试中发出了请求但没有被 expectOne() 或 match() 消费，这里就会抛出清晰的错误信息，例如：

Error: Expected no open requests, found 1: GET /api/users

这能立刻定位到哪个测试用例忘了验证请求，避免问题累积。

第三步：编写第一个测试用例

it('should return users from the API', () => {
  const mockUsers: User[] = [
    { id: 1, name: 'Alice', email: 'alice@example.com' },
    { id: 2, name: 'Bob', email: 'bob@example.com' }
  ];

  // Act: 调用服务方法
  service.getUsers().subscribe(users => {
    // Assert: 验证返回数据
    expect(users).toEqual(mockUsers);
  });

  // Arrange: 使用 HttpTestingController 模拟响应
  const req = httpMock.expectOne('/api/users'); // 匹配 URL
  expect(req.request.method).toBe('GET'); // 验证请求方法
  req.flush(mockUsers); // 发送模拟响应
});

这段代码的执行顺序是：先 service.getUsers() 触发请求并订阅，此时请求被 HttpClientTestingModule 拦截并放入队列；然后 httpMock.expectOne() 从队列中取出并验证；最后 req.flush() 触发 Observable 的 next() 。注意 subscribe() 必须在 expectOne() 之前调用，否则请求根本不会发出。

3.2 处理复杂请求场景：Headers、Params、Body、Error 的全路径覆盖

真实业务中的 HTTP 请求远不止 GET /api/users 。下面逐一拆解如何用 HttpTestingController 精确模拟和验证。

场景一：带查询参数和自定义 Header 的 GET 请求

假设 getUsers() 支持分页和搜索：

getUsers(page: number = 1, search: string = ''): Observable<User[]> {
  let params = new HttpParams().set('page', page.toString());
  if (search) {
    params = params.set('q', search);
  }
  return this.http.get<User[]>(this.baseUrl, {
    headers: { 'X-Client-ID': 'web-app-v1' },
    params
  });
}

测试代码需同步验证 Params 和 Headers：

it('should send GET with params and custom header', () => {
  const mockUsers: User[] = [{ id: 1, name: 'Alice' }];

  service.getUsers(2, 'alice').subscribe();

  const req = httpMock.expectOne(
    req => req.url === '/api/users' &&
           req.params.get('page') === '2' &&
           req.params.get('q') === 'alice' &&
           req.headers.get('X-Client-ID') === 'web-app-v1'
  );

  expect(req.request.method).toBe('GET');
  req.flush(mockUsers);
});

注意： expectOne() 接收一个谓词函数（predicate），比字符串匹配更灵活。这里我们用箭头函数检查 req.url 、 req.params 和 req.headers 的具体值。 req.params.get() 和 req.headers.get() 是安全的，即使参数不存在也返回 null ，不会报错。

场景二：POST 请求与请求体验证

UserService 还有一个 createUser 方法：

createUser(user: Partial<User>): Observable<User> {
  return this.http.post<User>(this.baseUrl, user, {
    headers: { 'Content-Type': 'application/json' }
  });
}

测试不仅要模拟响应，还要验证发送的请求体是否正确：

it('should POST a new user with correct body', () => {
  const newUser = { name: 'Charlie', email: 'charlie@example.com' };
  const createdUser = { id: 3, ...newUser };

  service.createUser(newUser).subscribe(user => {
    expect(user).toEqual(createdUser);
  });

  const req = httpMock.expectOne('/api/users');
  expect(req.request.method).toBe('POST');
  expect(req.request.body).toEqual(newUser); // ← 关键：验证请求体
  expect(req.request.headers.get('Content-Type')).toBe('application/json');

  req.flush(createdUser);
});

场景三：模拟 HTTP 错误响应（400、500 等）

业务代码必须健壮地处理后端错误。假设 getUsers() 在出错时返回一个 Observable<never> （即只触发 error ）：

getUsers(): Observable<User[]> {
  return this.http.get<User[]>(this.baseUrl).pipe(
    catchError(error => {
      console.error('Failed to load users:', error);
      return throwError(() => new Error('Network error'));
    })
  );
}

测试需验证错误路径是否被正确捕获：

it('should handle HTTP error and throw custom error', (done: DoneFn) => {
  const errorResponse = new HttpErrorResponse({
    error: { message: 'Internal Server Error' },
    status: 500,
    statusText: 'Internal Server Error',
    url: '/api/users'
  });

  service.getUsers().subscribe({
    next: () => fail('should not succeed'),
    error: (err: Error) => {
      expect(err.message).toBe('Network error');
      done(); // ← 异步测试必须调用 done()
    }
  });

  const req = httpMock.expectOne('/api/users');
  req.error(errorResponse); // ← 模拟 500 响应
});

req.error() 方法会触发 Observable 的 error 回调，完美复现网络异常或后端崩溃的场景。

3.3 高级技巧：批量请求、通配符匹配与响应延迟模拟

技巧一：处理多个相同 URL 的请求（如轮询）

有些场景会连续发多个相同 URL 的请求，比如健康检查轮询。 expectOne() 会报错，因为队列里有多个匹配项。此时用 match() ：

it('should handle multiple GET requests to same URL', () => {
  // 模拟服务内部发了两次请求
  service.getUsers().subscribe();
  service.getUsers().subscribe();

  // match() 返回所有匹配的请求数组
  const requests = httpMock.match('/api/users');
  expect(requests.length).toBe(2);

  // 分别 flush 不同的响应
  requests[0].flush([{ id: 1, name: 'Alice' }]);
  requests[1].flush([{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }]);
});

技巧二：URL 通配符匹配（应对动态 ID）

当 URL 包含动态部分，如 /api/users/123 ，用正则表达式：

it('should GET user by dynamic ID', () => {
  service.getUserById(123).subscribe();

  // 使用正则匹配 /api/users/ 后跟任意数字
  const req = httpMock.expectOne(/\/api\/users\/\d+/);
  expect(req.request.url).toMatch(/\/api\/users\/123/);

  req.flush({ id: 123, name: 'Alice' });
});

技巧三：模拟网络延迟（验证 loading 状态）

UI 组件常根据 loading$ Observable 显示加载动画。要测试这个，需让响应延迟：

it('should set loading state while request is in progress', fakeAsync(() => {
  const component = TestBed.createComponent(UserListComponent);
  const fixture = component.fixture;
  const service = TestBed.inject(UserService);

  // Spy on service to capture the Observable
  spyOn(service, 'getUsers').and.returnValue(
    of([{ id: 1, name: 'Alice' }]).pipe(delay(100)) // 模拟 100ms 延迟
  );

  fixture.detectChanges();
  expect(component.componentInstance.loading).toBeTrue();

  tick(100); // 等待 100ms
  fixture.detectChanges();
  expect(component.componentInstance.loading).toBeFalse();
}));

这里用到了 fakeAsync 和 tick() ，它们是 Angular 测试工具链的一部分，能精确控制异步时间流，比 setTimeout 更可靠。

4. 常见问题与实战排错指南

4.1 典型错误现象与根因分析

我在 Code Review 中高频看到的 HTTP 测试失败，基本可以归为以下五类，每一种都附带现场诊断方法：

注意： httpMock['pendingRequests'] 是访问私有属性的调试技巧，仅用于开发阶段诊断，生产代码中禁止使用。

4.2 实操避坑心得：那些文档里不会写的细节

心得一：永远用 expectOne() ，而不是 expectOne().flush() 的链式调用

新手常写：

httpMock.expectOne('/api/users').flush([{id:1}]); // ❌ 危险！

这看起来简洁，但隐藏巨大风险：如果 expectOne() 没匹配到请求，它会返回 undefined ，然后 undefined.flush() 抛出 Cannot read property 'flush' of undefined ，错误堆栈指向 .flush() 这一行，你根本看不出是 expectOne() 失败了。正确写法是分开两行：

const req = httpMock.expectOne('/api/users'); // ✅ 第一步：明确获取请求对象
req.flush([{id:1}]); // ✅ 第二步：在确认 req 存在后 flush

这样，错误会清晰地指向 expectOne() 行，定位更快。

心得二： req.flush() 的响应类型必须与 HttpClient 的泛型一致

如果你的 get<User[]>() 返回 User[] ，那么 req.flush() 必须传入 User[] 类型的数组，不能传入 { data: [...] } 这样的包装对象。否则，TypeScript 编译会报错，或者运行时 subscribe() 收到的数据结构与预期不符。我见过一个项目，后端返回 { success: true, data: [...] } ，前端却直接 http.get<User[]>('/api/users') ，导致 flush({data: [...]}) 后 users 变成了 undefined 。解决方案是：要么修改泛型为 http.get<{data: User[]}>() ，要么在 flush() 时传入 mockResponse.data 。

心得三： HttpTestingController 的 verify() 是最终防线，但不能替代逐条验证

有些团队为了“省事”，只在 afterEach() 里 httpMock.verify() ，而不为每个测试用例写 expectOne() 。这是严重误区。 verify() 只告诉你“有请求没处理”，但不告诉你“是哪个请求、在哪个测试里、为什么没处理”。它无法替代对业务逻辑的精确断言。比如，一个测试本应发 GET /api/users ，结果因为 bug 发了 GET /api/user （少了个 s）， verify() 会失败，但你得花时间去翻日志找是哪个测试错了。而 expectOne('/api/users') 会在那个测试里立刻失败，错误信息直指问题核心。

心得四：拦截器测试必须显式提供，且顺序敏感

如果你的服务依赖 AuthInterceptor ，测试中必须显式提供：

TestBed.configureTestingModule({
  imports: [HttpClientTestingModule],
  providers: [
    UserService,
    AuthInterceptor,
    { provide: HTTP_INTERCEPTORS, useClass: AuthInterceptor, multi: true }
  ]
});

而且 multi: true 是必须的，因为 HttpClientTestingModule 内部也注册了一个 NoopInterceptor （空拦截器）， multi: true 确保你的拦截器和内置拦截器共存。如果漏掉 multi: true ，你的拦截器会被完全忽略。

4.3 性能与可维护性优化：测试模板与共享工具函数

当项目中 HTTP 测试越来越多，重复代码（如 httpMock.expectOne().flush() ）会成为负担。我推荐两种轻量级优化方案：

方案一：创建 testHelper.ts 封装常用断言

// test-helper.ts
export function expectGetRequest(
  controller: HttpTestingController,
  url: string,
  response: any,
  status: number = 200
): void {
  const req = controller.expectOne(url);
  expect(req.request.method).toBe('GET');
  req.flush(response, { status, statusText: status === 200 ? 'OK' : 'Server Error' });
}

export function expectPostRequest(
  controller: HttpTestingController,
  url: string,
  body: any,
  response: any,
  status: number = 200
): void {
  const req = controller.expectOne(url);
  expect(req.request.method).toBe('POST');
  expect(req.request.body).toEqual(body);
  req.flush(response, { status });
}

在测试中直接调用：

it('should get users', () => {
  service.getUsers().subscribe();
  expectGetRequest(httpMock, '/api/users', mockUsers);
});

方案二：为复杂场景编写自定义 expect 匹配器（Jest 用户）

如果你用 Jest，可以扩展 expect API：

// jest.setup.ts
expect.extend({
  toHaveBeenCalledWithUrl(received, url) {
    const pass = received.url === url;
    if (pass) {
      return {
        message: () => `expected ${received.url} not to equal ${url}`,
        pass: true
      };
    } else {
      return {
        message: () => `expected ${received.url} to equal ${url}`,
        pass: false
      };
    }
  }
});

然后在测试中：

const req = httpMock.expectOne('/api/users');
expect(req.request).toHaveBeenCalledWithUrl('/api/users'); // 更语义化

这些优化不改变底层逻辑，只是让测试代码更易读、更易维护，把注意力聚焦在“业务行为”上，而不是“测试胶水代码”上。

5. 工具链整合与 CI/CD 实践建议

5.1 与主流测试框架（Jest/Karma）的兼容性要点

HttpClientTestingModule 是 Angular 官方模块，与 Karma/Jasmine 和 Jest 都完全兼容，但配置细节有差异：

• Karma/Jasmine（Angular CLI 默认） ：开箱即用，无需额外配置。 TestBed 的 DI 机制在 Karma 的浏览器环境中运行稳定。
• Jest ：需确保 jest-preset-angular 版本 >= 12.0.0，它内置了对 HttpClientTestingModule 的支持。关键配置在 jest.config.js ：

  module.exports = {
    preset: 'jest-preset-angular',
    setupFilesAfterEnv: ['<rootDir>/src/setup-jest.ts'],
    // 必须启用此选项，否则 Jest 无法解析 Angular 的装饰器
    transform: {
      '^.+\\.(ts|js|html)$': 'ts-jest'
    }
  };
  

  注意： setup-jest.ts 中需调用 jest.useFakeTimers() ，否则 fakeAsync 和 tick() 会失效。

无论用哪种框架，核心原则不变： 测试的可靠性不取决于框架，而取决于你是否严格遵循 expectOne() + flush() 的契约 。

5.2 在 CI/CD 流水线中保障 HTTP 测试质量

HTTP 测试是单元测试的“心脏”，必须在 CI 中 100% 通过。我的建议是三层防护：

第一层：本地开发强制钩子（pre-commit） 用 husky + lint-staged 在提交前运行 ng test --watch=false --code-coverage=false 。确保每个 PR 的 HTTP 测试都能通过，避免把“测试红了”的代码合入主干。

第二层：CI 流水线并行化 在 GitHub Actions 或 GitLab CI 中，将测试拆分为多个 job 并行执行：

# .github/workflows/test.yml
jobs:
  unit-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm ci
      - run: ng test --watch=false --code-coverage=false --browsers=ChromeHeadlessCI
  e2e-test:
    # ... 独立的 e2e job

关键是 --browsers=ChromeHeadlessCI ，它使用无头 Chrome，比默认的 PhantomJS 更接近真实环境，能捕获更多兼容性问题。

第三层：覆盖率门禁（Coverage Gate） 在 angular.json 中配置：

"test": {
  "options": {
    "codeCoverage": true,
    "codeCoverageExclude": ["**/*.spec.ts", "**/test-utils.ts"]
  }
}

然后在 CI 中添加覆盖率检查脚本，要求 src/app/**/user.service.spec.ts 的分支覆盖率（Branch Coverage）必须 ≥ 90%。这能强制团队为 catchError 、 retry 等错误处理路径编写测试，而不是只测 happy path。

5.3 从单元测试到 E2E 的演进路径：何时该用 Cypress？

HttpClientTestingModule 解决的是“服务层”契约。但当你要验证“用户点击按钮 → 发出请求 → 页面渲染数据 → 显示成功提示”这一完整链路时，单元测试就力不从心了。这时，应该引入 E2E 工具，如 Cypress 。

Cypress 的优势在于：它在真实浏览器中运行，能捕获 HttpClient 、拦截器、路由守卫、组件渲染、DOM 交互的全部副作用。你可以这样写一个 E2E 测试：

// cypress/e2e/user-list.cy.ts
cy.visit('/users');
cy.get('button[data-cy="load-users"]').click();
cy.intercept('GET', '/api/users').as('getUsers'); // ← Cypress 的 intercept
cy.wait('@getUsers').its('response.statusCode').should('eq', 200);
cy.get('[data-cy="user-item"]').should('have.length', 2);

这里 cy.intercept() 的作用，和 HttpTestingController 类似，但作用域是整个浏览器会话，而非单个 TestBed 。所以， 单元测试（HttpClientTestingModule）和 E2E（Cypress）不是替代关系，而是互补关系：前者保证“服务逻辑正确”，后者保证“端到端流程正确” 。一个健康的 Angular 项目，应该同时拥有这两层测试，形成质量护城河。

我个人在实际操作中发现，团队最容易犯的错误是“测试分层失衡”：要么只写 E2E，导致每次 CI 跑 10 分钟，反馈太慢；要么只写单元测试，上线后才发现 UI 组件没正确订阅 Observable 。我的经验是： 80% 的逻辑用 HttpClientTestingModule 覆盖，20% 的关键用户旅程用 Cypress 验证 。这个比例，经过我们三个项目的实践验证，能在质量、速度和维护成本之间取得最佳平衡。