先把组件从页面里“抽出来”,再为它建立一组可复现的输入与预期输出,最后用这些样例去比对不同页面的实际表现。验收样例的核心不是截图,而是能独立运行的组件状态集合。
同一个组件在不同页面表现不同,通常有三类原因:宿主页面的布局上下文不同、组件接收的数据不同、组件内部状态被外部代码改动。验收样例要能区分这三类,否则你只是在反复比对截图。
一个可执行的做法是:把组件单独挂到一个空白页面,给它固定输入,观察是否仍然出现差异。如果空白页里表现一致,说明问题在宿主页面;如果空白页里也能复现,说明问题在组件本身或数据。
以你手上的一个商品卡片组件为例。它在列表页显示正常,在详情页侧栏里文字被截断。不要直接改样式,先记录两个页面给这个组件传了什么。
差异点不是“页面不同”,而是容器宽度和是否带副标题。把这两项写成样例输入,验收样例就从一个模糊的“页面表现”变成两组明确条件。
样例必须包含预期结果,否则无法判定通过与否。预期结果要写成可观察的现象,而不是“显示正常”。
判定方式可以是人工检查,也可以是脚本读取渲染后的高度和文本截断状态。关键是每个样例都有明确的通过条件。
只测组件的好处是快、稳定,适合定位组件内部问题;代价是可能漏掉宿主页面带来的布局挤压。连宿主页面一起测的好处是接近真实场景;代价是样例数量会随页面数量增长,维护成本高。
选择条件可以这样定:如果差异只在某个页面出现,先做组件级样例,确认组件本身在固定输入下是否正常;如果多个页面都出现类似差异,再做宿主页面级样例,把页面布局参数也纳入输入。前者用于缩小范围,后者用于防止回归。
假设你有一个标签组件,在文章页显示为单行,在侧栏显示为两行。你可以构造三个固定宽度样例:360px、280px、200px,分别传入相同长度的标签文本。
如果 280px 下组件仍然单行,而侧栏实际宽度也是 280px,那么差异就不在宽度,而在侧栏的父级样式或字体设置。这个结果会直接改变下一步:不再调整组件断行规则,而是去检查侧栏容器的继承样式。
验收样例的价值就在这里:它让“表现不同”变成“哪个输入不同”,从而决定下一步是改组件、改宿主页面,还是改数据。