Write Jest Tests — Complete Anatomy

同学们，大家好！今天我们讲讲Lightning Web Components的测试，用的是Jest框架。这部分内容看起来复杂，但我会一步一步给你拆解，保证你听完就明白。 首先，咱们要记住，Jest测试遵循一个“八步解剖法”，其实就是一套标准的测试流程。第一步，我们用`createElement`来创建一个组件实例，语法是`createElement(‘c-mycomponent’, { is: MyComponentClass })`，这就像在代码里“造”一个组件出来。第二步，调用`appendChild`把这个元素加到文档里，这一步会触发组件的生命周期钩子，比如`connectedCallback`，组件才算真正活起来。然后，我们要访问组件的内部DOM，测试中得用`element.shadowRoot`，这是测试专用的API，相当于生产环境里的`this.template`，专门用来查看影子DOM里面的元素。 测试完每个用例，一定要在`afterEach`里做清理，比如`while (document.body.firstChild) document.body.removeChild(document.body.firstChild)`。这非常关键！因为Jest用的jsdom环境是跨测试共享的，要是不清理干净，前一个测试残留的DOM可能会干扰后面的测试，导致结果错乱。 接下来是导航测试。LWC里如果你用了`CurrentPageReference`这类导航服务，测试时需要模拟。别担心，`sfdx-lwc-jest`已经提供了默认的模拟实现，但你也可以自己定制，通过Jest配置的`moduleNameMapper`来映射到你的自定义模拟文件。 再来说Apex调用。如果组件里调用了Salesforce服务端的方法，比如导入`import getAccount from '@salesforce/apex/AccountController.getAccount'`，测试里必须模拟它。做法是：在同目录或者`__tests__`下放一个同名Apex模拟文件，里面导出`jest.fn()`。还要在Jest配置里加上模块名重定向，把`@salesforce/apex/`开头的模块统统指向一个通用的模拟实现。这样测试就不会真的去调服务器了。 还有异步DOM更新的问题。如果你设置组件属性是在`appendChild`之后，那会触发异步渲染，测试里需要用`return Promise.resolve()`来等待微任务执行完，才能获取到最新的DOM。但如果你在`appendChild`之前设置属性，那就是同步更新，不需要`Promise`处理。简单说：先设属性，再挂载，就同步；先挂载，再改属性，就异步。 最后，有个安全保障：`.forceignore`文件。要让测试文件不被部署到Salesforce生产环境，你可以在`.forceignore`里加入模式来忽略测试文件夹，比如`，/__tests__/，`，这样部署时就会自动跳过它们，确保测试代码不会进到组织里。 把这些点记住，LWC的测试就能写得得心应手。好，这节课就到这里，下一节我们动手写一个实际例子。