Angular+Express项目单元/集成测试时CSRF中间件处理方案选型

咱们先拆解下这两个方案的优劣势，再结合你的Angular+Express+csurf+supertest的场景来判断哪个更适配：

方案一：测试环境禁用CSRF中间件 #

优点 #

• 实现成本极低：只需要在Express的中间件配置里加个环境判断，测试代码完全不用改动，能最快解决当前的ForbiddenError问题
• 简化测试逻辑：不用在测试流程中额外处理CSRF token的获取和携带，专注于业务逻辑的验证

缺点 #

• 测试环境与生产环境不一致：生产环境启用了CSRF防护，但测试环境直接跳过，可能导致生产环境中出现的CSRF配置问题（比如cookie参数错误、token传递逻辑异常）无法在测试中被发现
• 测试覆盖有盲区：无法验证CSRF中间件本身的工作逻辑是否正常

代码示例 #

const csurf = require('csurf');

// 仅在非测试环境启用CSRF中间件
if (process.env.NODE_ENV !== 'test') {
  // 根据你的实际配置调整参数（比如cookie的domain、secure等）
  app.use(csurf({ cookie: true }));
}

方案二：测试环境暴露CSRF Token接口，请求时携带 #

优点 #

• 测试环境贴近生产：完全复用生产环境的中间件栈，测试流程和真实用户请求逻辑一致，能覆盖CSRF token的生成、传递、验证全流程
• 测试覆盖更全面：可以验证CSRF中间件的配置是否正确，避免出现“测试通过但生产环境因为CSRF防护报错”的情况

缺点 #

• 测试代码复杂度增加：需要在测试用例中先获取token，再携带到后续请求中，多了一个前置步骤

代码示例 #

后端（Express）添加测试专用接口

// 仅在测试环境暴露获取CSRF token的接口
if (process.env.NODE_ENV === 'test') {
  app.get('/test/csrf-token', (req, res) => {
    res.json({ csrfToken: req.csrfToken() });
  });
}

前端测试（supertest）获取并携带token

const request = require('supertest');
const app = require('../app');

describe('API 业务逻辑测试', () => {
  let csrfToken;

  // 每个测试用例前先获取CSRF token
  beforeEach(async () => {
    const tokenResponse = await request(app).get('/test/csrf-token');
    csrfToken = tokenResponse.body.csrfToken;
  });

  it('创建资源接口应正常响应（携带有效CSRF token）', async () => {
    await request(app)
      .post('/api/resources')
      // 根据你的csurf配置设置请求头，通常是X-CSRF-Token或X-XSRF-TOKEN
      .set('X-CSRF-Token', csrfToken)
      .send({ name: '测试资源' })
      .expect(201);
  });
});

适配建议 #

• 如果你的测试核心目标是快速验证业务逻辑正确性，且团队有单独的生产环境配置验证流程（比如上线前手动检查CSRF配置），那么方案一是更高效的选择，能节省测试代码的编写成本
• 如果你的测试目标是尽可能模拟生产环境的真实请求场景，希望覆盖CSRF防护的全流程逻辑，避免生产环境出现未被测试到的配置问题，那么方案二更合适，能提升测试的可靠性

另外补充个小技巧：如果你的Angular生产环境中是通过cookie自动传递CSRF token（Angular默认会读取XSRF-TOKEN cookie并在请求头中携带X-XSRF-TOKEN），测试时也可以模拟这个行为——先请求一个会设置CSRF cookie的接口，再从cookie中提取token，这样更贴近真实前端的请求方式。

内容的提问来源于stack exchange，提问作者cusejuice