Vitest浏览器测试中Interactivity API的Shift键状态问题分析

在Vitest的浏览器测试环境中，开发者在使用Interactivity API进行交互测试时遇到了一个关于键盘修饰键状态的问题。具体表现为：当使用userEvent.keyboard('{Shift>}')模拟按下Shift键后，后续的指针事件（如click）中event.shiftKey属性未能正确反映Shift键的按下状态。

问题背景

在实现多选功能时，开发者通常会监听指针事件（如pointerup或click）并检查event.shiftKey属性来判断是否应该执行多选操作。测试代码通常会这样编写：

const user = userEvent.setup();
await user.keyboard('{Shift>}');
await user.click(thirdItem);
await user.keyboard('{/Shift}');

然而，在Vitest的preview provider环境下，虽然keyboard命令成功发送了Shift键按下的信号，但在后续的click事件中，event.shiftKey却显示为false，导致测试失败。

问题根源

经过分析，这个问题主要存在于Vitest的preview provider实现中。preview provider内部直接使用了testing-library的userEvent实现，而该实现在处理键盘修饰键状态与指针事件的同步上存在缺陷。

当使用playwright或webdriverio作为provider时，由于它们直接调用浏览器原生API，能够正确保持键盘状态，因此不会出现这个问题。这表明问题并非Vitest核心功能的问题，而是特定provider的实现细节。

解决方案

对于遇到此问题的开发者，有以下几种解决方案：

1. 切换测试provider：在可能的情况下，优先使用playwright作为provider，它能够正确处理键盘状态。

2. 直接检查元素状态：如果测试逻辑允许，可以不依赖事件对象的shiftKey属性，而是直接验证多选后的元素状态。

3. 使用原生事件API：在preview环境下，可以考虑直接使用document.dispatchEvent来创建和发送包含正确键盘状态的事件对象。

最佳实践建议

1. 对于复杂的交互测试，特别是涉及键盘修饰键的场景，推荐使用playwright provider。

2. 在编写测试时，考虑将键盘状态验证与功能验证分离，提高测试的健壮性。

3. 对于跨provider的测试套件，建议添加provider特定的测试条件或跳过某些provider不支持的测试场景。

总结

这个问题揭示了前端测试中一个常见的挑战：不同测试工具对浏览器API的模拟实现可能存在差异。作为开发者，理解这些差异有助于编写更可靠的测试代码。Vitest团队已经确认这是一个需要修复的bug，在未来的版本中可能会得到改进。在此之前，开发者可以通过选择合适的provider或调整测试策略来规避这个问题。