多参数组合排序函数单元测试的Stub对象命名方案探讨

看起来你遇到的是单元测试中「测试数据可读性」和「维护便捷性」的经典矛盾，我之前做排序类函数测试时也踩过类似的坑，分享几个我觉得实用的折中方案：

方案1：内联用例数据+复用元素生成函数 #

这种方式既能让测试代码直接展示输入输出的逻辑，又能避免重复编写元素结构：

首先在测试文件（或者单独的测试工具文件）里写一个通用的元素生成函数：

// 可以放在测试文件顶部，或者单独的test-utils.js里
const createTask = (priority, duration) => ({ priority, duration });

然后在测试用例里直接内联组合数据：

describe('Custom Sorter', () => {
  it('should prioritize duration over raw priority', () => {
    // 输入和输出的逻辑关系一目了然
    const input = [createTask(1, 20), createTask(2, 30)];
    const expected = [createTask(2, 30), createTask(1, 20)];
    
    expect(customSorter.sort(input)).toEqual(expected);
  });

  it('should handle tasks with same duration but different priority', () => {
    const input = [createTask(3, 15), createTask(1, 15)];
    const expected = [createTask(1, 15), createTask(3, 15)];
    
    expect(customSorter.sort(input)).toEqual(expected);
  });
});

优点：测试用例里直接能看到输入输出的逻辑关系，不用跳转查看Stub；如果需要修改任务的结构（比如加个id字段），只需要修改createTask函数，所有测试用例自动同步。
缺点：如果有非常多重复的用例组合，还是会有一点代码重复，但比完全手写每个元素好很多。

方案2：封装完整测试用例对象 #

把每个测试场景的输入、预期输出和描述都封装成对象，集中管理，然后在测试里遍历执行：

// 集中定义所有测试用例，可以放在测试文件顶部或者单独的test-cases.js里
const sorterTestCases = [
  {
    description: 'should prioritize duration over raw priority',
    input: [{ priority: 1, duration: 20 }, { priority: 2, duration: 30 }],
    expected: [{ priority: 2, duration: 30 }, { priority: 1, duration: 20 }]
  },
  {
    description: 'should handle same duration, sort by priority',
    input: [{ priority: 3, duration: 15 }, { priority: 1, duration: 15 }],
    expected: [{ priority: 1, duration: 15 }, { priority: 3, duration: 15 }]
  },
  // 更多用例...
];

describe('Custom Sorter', () => {
  sorterTestCases.forEach(testCase => {
    it(testCase.description, () => {
      expect(customSorter.sort(testCase.input)).toEqual(testCase.expected);
    });
  });
});

优点：测试用例数据集中维护，修改时只改一处；测试代码非常简洁，每个用例的描述、输入输出都能在一个地方看到，可读性拉满。
缺点：如果需要动态生成测试数据（比如随机值、批量生成），这种静态对象的方式就不太灵活。

方案3：利用测试框架的参数化测试能力 #

如果你的测试框架支持参数化测试（比如Jest的test.each、Vitest的test.each），这是最推荐的方式，完美兼顾可读性和维护性：

以Jest为例：

describe('Custom Sorter', () => {
  test.each([
    [
      'prioritizes duration over raw priority',
      [{ priority: 1, duration: 20 }, { priority: 2, duration: 30 }],
      [{ priority: 2, duration: 30 }, { priority: 1, duration: 20 }]
    ],
    [
      'sorts by priority when durations are equal',
      [{ priority: 3, duration: 15 }, { priority: 1, duration: 15 }],
      [{ priority: 1, duration: 15 }, { priority: 3, duration: 15 }]
    ],
    // 更多用例...
  ])('%s', (description, input, expected) => {
    expect(customSorter.sort(input)).toEqual(expected);
  });
});

优点：测试数据和测试逻辑完全绑定，每个用例的场景、输入、输出都在同一行展示；新增/修改用例只需要在数组里添加/修改条目，非常方便；测试框架会自动为每个用例生成独立的测试报告。
缺点：依赖测试框架的参数化能力，但主流前端测试框架都原生支持，几乎没有门槛。

怎么选？ #

• 如果你的测试用例不多，且每个用例的逻辑差异大：选方案1，灵活且可读性强。
• 如果测试用例数量多，且需要统一管理：选方案2或方案3，后者更适合现代测试框架的使用习惯。
• 如果需要动态生成测试数据（比如批量生成边界值）：结合方案1的生成函数+方案3的参数化测试，能高效覆盖大量边缘场景。

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