如何用Bookshelf模型与Express服务器重构并测试API服务？

问题1：测试getRegions这类函数的正确方式是什么？ #

这得分两种核心场景来处理，完全取决于你想要覆盖的测试层级：

场景1：单元测试（隔离数据库与Express） #

如果你的目标是单独验证getRegions的业务逻辑本身，而非数据库交互或Express路由的完整流程，那Mock掉Bookshelf模型是最优解。这种测试速度极快，也不会受真实数据库状态的影响。

举个Jest框架下的简单示例：

// 服务文件：regionService.js
const Region = require('../models/Region');

exports.getRegions = async () => {
  return Region.fetchAll();
};

// 测试文件：regionService.test.js
const regionService = require('./regionService');
const Region = require('../models/Region');

// Mock整个Region模型
jest.mock('../models/Region');

test('getRegions应返回模拟的区域数据', async () => {
  // 预设fetchAll方法的返回值
  const mockRegions = [{ id: 1, name: '华北地区' }, { id: 2, name: '华东地区' }];
  Region.fetchAll.mockResolvedValue(mockRegions);

  const result = await regionService.getRegions();
  expect(result).toEqual(mockRegions);
  // 验证模型方法确实被调用了一次
  expect(Region.fetchAll).toHaveBeenCalledTimes(1);
});

场景2：集成测试（覆盖完整链路） #

如果你想验证从Express路由到数据库查询的全流程正确性，就需要用独立的测试数据库来做集成测试。核心步骤是：

• 测试前：创建测试数据库，运行迁移脚本初始化表结构，插入固定的测试种子数据
• 测试中：用supertest这类工具调用Express路由，验证返回数据与数据库状态匹配
• 测试后：清理数据库（比如回滚迁移，或用事务包裹测试自动回滚）

示例代码（supertest + Jest）：

const request = require('supertest');
const app = require('../app');
const db = require('../db'); // 你的数据库连接实例

beforeAll(async () => {
  // 初始化测试库：运行最新迁移
  await db.migrate.latest();
  // 插入测试用的种子数据
  await db.seed.run();
});

afterAll(async () => {
  // 清理测试库：回滚迁移并关闭连接
  await db.migrate.rollback();
  await db.destroy();
});

test('GET /regions应返回数据库中的所有测试区域', async () => {
  const response = await request(app).get('/regions');
  expect(response.statusCode).toBe(200);
  expect(response.body.length).toBeGreaterThan(0);
  // 验证返回数据与预设种子数据一致
  expect(response.body[0].name).toBe('测试区域1');
});

至于是否要包含数据库交互：单元测试不需要，集成测试必须要——两者搭配才能覆盖完整的测试场景。

问题2：最佳实践是否要求将getRegions和getSubregions从Express上下文中提取出来？ #

是的，这是后端开发的核心最佳实践之一。把业务逻辑从Express路由/中间件中抽离出来，有几个关键好处：

• 可测试性暴增：抽离后的服务函数可以单独测试，不需要启动Express服务器，也不用处理HTTP请求/响应对象的细节
• 代码复用性提升：如果其他地方（比如CLI工具、内部API、定时任务）需要调用getRegions，可以直接复用这个函数，不用重复编写逻辑
• 关注点更清晰：Express路由只负责处理HTTP层的事情（解析参数、返回状态码、处理HTTP层面的错误），业务逻辑放在独立的服务层，代码结构更易维护

举个重构前后的对比示例：

重构前（与Express强耦合） #

// routes/regions.js
const Region = require('../models/Region');

router.get('/regions', async (req, res) => {
  try {
    const regions = await Region.fetchAll();
    res.json(regions.toJSON());
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

重构后（分离服务层） #

// services/regionService.js
const Region = require('../models/Region');

exports.getRegions = async () => {
  const regions = await Region.fetchAll();
  return regions.toJSON();
};

// routes/regions.js
const regionService = require('../services/regionService');

router.get('/regions', async (req, res) => {
  try {
    const regions = await regionService.getRegions();
    res.json(regions);
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

重构后，getRegions完全独立于Express生态，你可以轻松为它编写单元测试，也能在任何需要的地方复用。

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