多数场景下用toBeInViewport()替代toBeVisible()是否存在弊端？

• 测试逻辑完全跑偏
  toBeVisible()校验的是元素本身是否被CSS隐藏——比如display: none、父元素设了visibility: hidden、元素透明度设为0这类情况，只要元素处于「可渲染且未被隐藏」的状态，不管它在不在当前浏览器视口，都会返回true。而toBeInViewport()只认元素是否出现在浏览器当前可见区域内。要是你测试的是页面底部的footer，默认状态下它不在视口但本身是可见的，换方法后测试直接失败，完全不符合你原本验证「元素存在且未被隐藏」的需求。

• 平白增加测试工作量
  有些场景根本不需要关心元素在不在视口，比如验证下拉菜单展开后选项是否可见——哪怕菜单太长导致部分选项超出视口，只要选项没被隐藏，就应该算通过。硬换成toBeInViewport()的话，你还得额外加滚动到元素位置的代码，纯纯给自己添活儿。

• 误判合法的「可见但不在视口」场景
  页面里很多元素本身是可见状态，但默认不在视口内，比如长页面的底部内容、未激活的tab面板里的内容，这些都是符合业务逻辑的正常情况。全量替换后，这些合法场景会被当成测试失败，直接搞砸测试的准确性。

• 和实际用户交互逻辑脱节
  有些时候，元素虽然不在当前视口，但本身是正常可见的，用户只要滚动就能交互。比如测试长页面中部的按钮是否可点击，用toBeVisible()能验证它没被隐藏，而toBeInViewport()会直接判定不通过，但实际这个按钮是完全正常的，这就导致测试结果和真实用户体验脱节。

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