博客建站指南：同一组件在不同页面表现不同时怎样构造验收样例
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /35f62511c2bf.html
📄
博客建站指南：同一组件在不同页面表现不同时怎样构造验收样例
先把“表现不同”拆成可观察的差异，再为每个差异写一条能复现的验收样例：固定输入、固定环境、记录输出，最后用同一份样例同时跑两个页面。如果只有一处差异，且换到另一页面就消失，那通常不是组件本身的问题，而是页面给它的上下文不同，验收样例要围绕这个上下文来写，而不是围绕组件重写一遍。
先区分三种“不同”，否则样例会写歪
同一组件在两处表现不同，原因大致落在三类里，验收样例的写法完全不同。
- 输入不同：页面传入的数据结构、字段数量、空值情况不一样。样例要固定数据，而不是固定页面。
- 环境不同：容器宽度、父级样式、脚本加载顺序、主题变量不同。样例要固定一个可复现的容器条件。
- 时序不同：组件在首屏渲染、异步数据到达后、或用户交互后才出现差异。样例要写明观察发生在哪个时刻。
判断方法很直接：把表现正常的那个页面里的组件，原样搬到出问题的页面位置。如果问题跟着位置走，是环境；如果问题跟着数据走，是输入；如果只在某个操作之后出现，是时序。这一步的结果决定你接下来写哪类样例，而不是先写一堆断言再回头找原因。
把一份现有页面转成可执行的验收样例
以你手上正在处理的那个页面为对象，按下面的顺序走一遍。
- 选一个最小可复现的页面：不要用整站，用能触发差异的最短路径页面。
- 记录进入条件：访问路径、登录状态、数据来源、是否带查询参数。这些是样例的前置条件，缺一项就可能复现不出来。
- 写一条观察项：只写一个可判断真假的句子，例如“组件在容器宽度小于 480px 时，标题不换行”。
- 写期望值与实际值：期望值来自表现正常的那个页面，实际值来自出问题的页面。
- 标注判定方式：肉眼可判断的写肉眼判断，需要代码断言的写断言位置，两者不要混在一条里。
一个假设例子：某列表组件在归档页显示三列，在文章页显示一列。样例可以写成“在容器宽度 1024px、父级无额外内边距时，该组件渲染为三列”。跑一次，如果文章页仍是一列，就去查父级内边距；如果变成三列，说明差异来自容器而非组件。这个结果直接决定下一步是改页面样式还是改组件默认值。
验收样例要写清的四件事
缺任何一件，样例都会在别人手里失效。
- 前置条件：数据、环境、状态三样都要有，不能只写“打开页面”。
- 操作步骤：按顺序写出做了什么，包括是否刷新、是否切换视口。
- 观察点：一次只看一个位置，避免一条样例覆盖多个结论。
- 判定标准：写清什么算通过、什么算不通过，不要留“基本正常”这类模糊说法。
如果同一组件要在多个页面复用，把公共前置条件抽成一份共享样例，各页面只写差异部分。这样改一处不会牵动全部页面，退掉某个旧页面时也只需删掉它的差异样例，公共部分仍然有效。
旧内容或旧系统退出时，样例怎么保留价值
当旧页面、旧模板或旧合作关系要退出，验收样例不该整批丢弃。先按下面的顺序筛一遍。
- 把样例按“组件行为”和“页面特有行为”分开。前者通常还能用，后者随页面一起退。
- 对仍要保留的组件行为，把页面特有的前置条件替换成通用条件，例如把具体栏目名换成占位数据。
- 对即将退出的页面，保留它的差异样例作为回归对照，直到新页面稳定后再删。
- 删除前跑一次保留样例，确认它们不依赖即将下线的数据源或路径。
这样做的结果是：旧页面退出后，组件层面的验收样例还能继续用，而页面特有的部分被干净地移除，不会留下一堆无法执行的断言行。
什么时候该补样例，什么时候该改组件
如果同一差异在三个以上页面重复出现，优先改组件的默认行为，而不是给每个页面补一条样例。反过来，如果差异只出现在一个页面，且该页面本身要退出，就不必为它补样例，直接在退出清单里标注即可。判断依据是差异的分布范围，不是差异看起来是否严重。分布广的差异靠改组件收口，分布窄的差异靠样例记录，两者不要互相替代。
把上面几步做完，你手上会得到一份能直接执行的样例清单，而不是一段关于“表现不一致”的描述。下一步就是拿这份清单去跑一遍，用跑出来的结果决定改组件还是改页面。
