Mock Patterns & DOM Inspection Considerations

同学们，今天我们来聊聊在 Lightning Web Components 测试中特别有用的技巧——模拟模式。掌握了它，你就能轻松应对那些不好直接测的场景。 咱们先从最基本的属性更改测试说起。当你创建一个组件实例，如果在调用了 `appendChild` 把它加到文档里之后，才去设置某个公共属性，那么渲染是异步的。这时候想要验证结果，就必须用 `Promise.resolve()` 等待微任务队列清空，否则断言会失败。反过来，如果你希望在附加前就完成赋值、实现同步渲染，可以先用 `Object.assign` 把属性一股脑儿设好，再 `appendChild`，这样就不用等 Promise 了，测试代码更简洁。 接着看组件间的交互。Salesforce 提供的 lightning 存根，比如 `lightning-button` 的模拟，只保证 API 接口兼容，但不会像真实组件那样自动触发事件。所以，假如你的组件监听了按钮的 `click` 事件，在测试里你得自己手动调度事件。用 `new CustomEvent` 然后 `dispatchEvent`，才能模拟用户点击的效果。 说到事件，必然要提事件处理函数的模拟。通常我们用 `jest.fn()` 创建一个假函数，然后通过 `addEventListener` 把它挂到元素上。手动调度事件之后，就可以用 `expect` 验证这个假函数被调用了几次，以及事件对象的 `detail` 属性是不是我们期望的值。这样不用关心内部实现，只看交互结果，测试更稳定。 还有模块导入的模拟。比如你用 `import` 引入了一个自己写的工具模块，或者 `@salesforce/label` 这种 Salesforce 特定范围导入。想控制它的返回结果怎么办？直接用 Jest 的 `jest.mock()`。给模块路径配一个工厂函数，返回你需要的假数据，这样就能隔离被测组件和外部依赖，让测试完全按你的剧本走。 最后要提醒大家：LWC 内部的 HTML 结构和 CSS 类名其实是不稳定的，官方不希望你把测试锚定在那些细节上。所以我们写单元测试时，尽量通过 `element.shadowRoot` 来访问影子 DOM，做一些高层级的检查就好，不要执着于具体的 CSS 选择器。真正需要验证页面外观和整体交互的时候，还是交给 Selenium 这类工具做端到端测试。记住，Jest 单元测试专注于逻辑和 API，Selenium 才负责端到端的用户体验。 把这些模拟手法用好，你的测试就会既健壮又灵活。赶紧去试试吧！