在React组件库的开发过程中，同一个基础组件往往会因为接收不同的Prop组合而呈现出完全不同的渲染结果。以常见的Button组件为例，它可能存在type、size、disabled、loading、icon等多种属性，这些属性彼此之间并不独立，某些组合还会触发特有的分支逻辑。如果仅仅依靠开发者本地手动传参查看界面，不仅效率低下，而且很容易遗漏边界组合。因此，我们需要一套系统化的测试方案，能够自动将多种Prop组合喂给组件，并验证其输出的DOM结构、文本内容以及类名是否符合预期。
为什么需要针对Prop组合做专门测试
组件库与业务项目中的一次性组件不同，它会被未知数量的外部用户反复引用。任何一个未被覆盖的Prop组合如果产生了错误的渲染，影响面都会放大。例如一个Card组件在同时传入bordered=false与hoverable=true时，原本应该隐藏边框但保留悬浮阴影，若内部条件判断写成了if (bordered || hoverable)就会错误地加上边框。这类问题在单一Prop测试中是发现不了的，必须依赖组合维度的验证。
从维护成本角度看，当组件库版本升级时，Prop的默认值或互斥关系可能发生变化。如果没有组合测试作为回归保护，维护者很难确认改动是否破坏了某种历史用法。通过把组合抽象为测试数据，我们可以在每次提交时自动跑完所有排列，一旦渲染结果偏离基线就立刻报警，这比人工回归节省了大量沟通与排查时间。
另外，组合测试还能反向推动组件API设计。当你尝试为某个组件列出全部合法Prop组合时，往往会发现某些组合在语义上矛盾，比如disabled和loading同时为真时的优先级不清晰。在写测试的过程中顺手补全文档或调整内部逻辑，能让组件库的契约更严谨。
使用参数化测试遍历Prop组合
Jest提供的it.each或test.each是处理Prop组合最直接的工具。我们可以把每一种组合写成一个对象，然后让测试运行器批量执行。下面的示例展示了一个简化版Button组件，以及如何使用矩阵方式测试它的渲染类名。
// Button.jsx
import React from 'react';
export function Button({ size = 'middle', disabled = false, loading = false, children }) {
const cls = ['btn'];
cls.push(`btn-${size}`);
if (disabled) cls.push('btn-disabled');
if (loading) cls.push('btn-loading');
return (
<button className={cls.join(' ')} disabled={disabled || loading}>
{loading ? '加载中...' : children}
</button>
);
}
上面的组件在loading为真时会覆盖子内容并显示文案，同时禁用按钮。接下来我们用参数化测试检查三种属性的排列。
// Button.test.jsx
import { render, screen } from '@testing-library/react';
import { Button } from './Button';
const combinations = [
{ size: 'middle', disabled: false, loading: false, expectCls: 'btn btn-middle', expectText: '提交' },
{ size: 'small', disabled: true, loading: false, expectCls: 'btn btn-small btn-disabled', expectText: '提交' },
{ size: 'large', disabled: false, loading: true, expectCls: 'btn btn-large btn-loading', expectText: '加载中...' },
{ size: 'small', disabled: true, loading: true, expectCls: 'btn btn-small btn-disabled btn-loading', expectText: '加载中...' }
];
test.each(combinations)('渲染组合: %o', (c) => {
render(<Button size={c.size} disabled={c.disabled} loading={c.loading}>提交</Button>);
const btn = screen.getByRole('button');
expect(btn.className).toBe(c.expectCls);
expect(btn).toHaveTextContent(c.expectText);
if (c.disabled || c.loading) {
expect(btn).toBeDisabled();
} else {
expect(btn).not.toBeDisabled();
}
});
这种写法把组合数据和断言逻辑分离，当组件新增danger属性时，只需要在combinations数组里补充条目，无需改动测试主体。相比为每个组合手写一条it，参数化能显著降低重复代码，也方便非核心开发者补充用例。
需要注意的是，当Prop数量较多时，全排列会产生指数级用例。此时可以借助笛卡尔积工具只生成“有意义”的组合，或利用等价类划分挑出代表性集合，避免测试时间失控。例如size有三个值，disabled和loading各有两个值，全量是12种，若业务上明确loading隐含禁用，则可合并部分分支。
结合快照与查询接口验证渲染差异
除了类名与文本，某些Prop组合会改变DOM层级，比如icon存在时多出一个span节点。此时单靠类名断言不够，可以配合React Testing Library的查询接口深入检查结构，或者对特定组合使用快照。
// 结构差异测试示例
import { render, screen } from '@testing-library/react';
import { Button } from './Button';
test('带icon时渲染额外图标节点', () => {
const { container } = render(<Button icon="search">搜索</Button>);
const iconSpan = container.querySelector('.btn-icon');
expect(iconSpan).not.toBeNull();
expect(screen.getByText('搜索')).toBeInTheDocument();
});
快照适合捕捉“整棵子树”的意外变动，但不建议对全部组合都开快照，否则一旦基础样式调整，成百上千个快照文件都会失败，维护者只能盲目更新。更稳妥的做法是：只对核心组合或易错组合留存快照，其余组合用精确的查询断言。这样既能防回归，又不会让快照膨胀拖慢CI。
在实际组件中，还可以用rerender模拟Prop动态变化。比如先以loading=false渲染，再改为loading=true，验证组件是否从正常态平滑切换到加载态，而不会残留旧文本。这种“组合切换”测试比静态组合更贴近用户操作路径，能发现状态清理不彻底的问题。
最后，把组合测试接入流水线是关键一步。在GitHub Actions或类似平台上，每次PR都执行jest命令，失败时直接阻断合并。配合覆盖率统计，我们能清楚看到哪些Prop分支还没被组合用例触达，从而持续完善矩阵。组件库的稳定性，正是从这些看似琐碎的排列验证中积累出来的。