测试

这套资料的主题是前端测试，不是"测试一下能不能跑"的那种测试，而是把测试当成工程能力来对待的完整内容。很多人学前端时把测试放在最后，觉得先把页面写出来再说，结果项目一大，改一个组件崩三个页面，每次发版都靠人肉点一遍。这套东西要解决的就是这个具体问题：让前端的正确性可以被自动验证，而不是靠记忆和运气。

需要先说明的是，前端测试这个概念本身被用得很乱。有人说的测试是写完函数随手 console.log 看一眼，有人说是单元测试覆盖率，有人说是端到端跑一遍浏览器。这套资料的价值在于它把这几个层次分开讲清楚了，而不是混在一起喊口号。你如果只是想知道"前端测试到底是什么、我该从哪一层开始"，这份内容足够给你一个明确的坐标系。

它要解决的核心问题：改动之后你敢不敢发

前端测试真正要回答的问题只有一个：你改了一处代码，怎么知道没有把别的地方弄坏。这个问题在小项目里不明显，因为你能记住所有逻辑。但只要组件超过几十个、状态开始跨层传递、接口返回的字段偶尔缺一个，人脑就不可靠了。这时候如果没有自动化验证，唯一的办法就是每次改动都手动把主要流程点一遍，时间成本高，而且总会漏。

这套内容围绕的就是建立这种自动验证的能力。它会让你理解测试不是额外负担，而是把"我改完大概没问题"变成"我改完确定没问题"的手段。这个转变对前端尤其重要，因为前端的状态组合比后端复杂得多，一个按钮的禁用状态可能取决于五六个变量的组合，靠手动点根本覆盖不全。

另一个被解决的是认知问题。很多前端开发者对测试有抵触，觉得写测试的时间不如多写两个页面。这套资料如果讲得扎实，会让你看到测试在什么场景下回报最高——不是所有代码都值得测，但那些被反复修改、被多处依赖的核心逻辑，测一次能省下后面几十次手动验证。

适合什么基础的人看，以及不适合谁

看这套内容之前，你至少应该能独立写一个带状态管理的前端应用，理解组件、props、事件、异步请求这些基本概念。如果还没到这一步，直接看测试会非常痛苦，因为你连被测对象都还没搞明白。测试是建立在"你已经会写代码"之上的能力，不是入门内容。

具体来说，你需要熟悉至少一个主流框架的组件写法，知道什么是模块导入导出，能看懂 Promise 和 async/await。如果这些还模糊，建议先把框架本身用熟再来。另外，如果你从没写过任何自动化脚本，对"断言"这个词完全陌生，那前几节可能需要慢一点，把基本概念吃透再往下。

不适合的人也很明确：只想快速做出一个页面交差、不打算长期维护项目的人，看这套内容会觉得多余。测试的收益来自长期反复修改，一次性交付的东西确实没必要投入。但只要你打算在一个项目上待超过三个月，或者要和别人协作，这套东西的性价比就会立刻显现出来。

建议先精看的几块内容

第一块是测试的基本概念和断言思路。这部分决定了你后面所有实践的底层理解。很多人跳过概念直接抄测试代码，结果写出来的测试要么什么都测不出来，要么一改实现就全红。先把"测什么、不测什么、断言应该断在哪一层"想清楚，后面会顺很多。

第二块是针对组件行为的测试。前端测试和后端最大的区别就是它要面对用户交互，点击、输入、异步加载、条件渲染，这些才是前端测试的主战场。这块内容值得反复看，因为它直接对应你日常写的东西。看的时候不要只记写法，要理解为什么这样组织测试用例，一个组件应该被拆成几个测试场景。

第三块是异步和副作用的处理。前端几乎处处是异步，接口请求、定时器、事件监听，这些如果处理不好，测试会变得极不稳定，时而通过时而失败。这块是区分"会写测试"和"写得能用的测试"的关键，值得单独花时间精看，把常见的等待和模拟手段弄清楚。

学完之后能独立做什么

学完并动手练过之后，你应该能给自己项目里的核心组件写出可运行的测试，覆盖正常流程和几个关键边界情况。你能判断哪些代码值得测、哪些不值得，而不是机械地追求覆盖率数字。这个判断力比会写测试语法更重要，也是这套内容真正想给你的东西。

更进一步，你能在改动代码后跑一遍测试，快速确认没有破坏已有功能，把回归验证从手动变成自动。你也能看懂别人项目里的测试文件，知道它在验证什么、哪里可能漏了。这在接手他人代码或者参与协作时非常实用，因为测试文件往往是最好的行为说明书。

如果你练得够多，还能进一步处理测试的组织问题：怎么避免测试之间互相影响，怎么让测试跑得快，怎么在提交前自动执行。这些属于进阶能力，但基础打牢之后是可以自己摸索出来的，不需要每一步都等人教。

资料怎么配合练习用

这套资料不要当成视频看完就算。正确的用法是一边看一边在自己已有的项目里找对应场景动手。比如看到组件测试那一块，就打开你手头项目里最复杂的一个组件，试着给它写第一个测试。写不出来再回去看，这种来回比单纯刷完所有内容有效得多。

练习时建议从最小的单元开始，先测一个纯函数，再测一个简单组件，最后才碰带异步和状态依赖的部分。跳步会让你在早期就遇到挫败感，而循序渐进能让你每一步都有正反馈。每写完一个测试，故意改坏被测代码，看测试能不能报错——这是检验测试是否真的有效的最直接方法，很多人写出来的测试其实永远通过，等于没写。

资料本身可以拆成概念、组件、异步三部分分别消化，不必按顺序一次刷完。哪部分在工作中先遇到问题，就先看哪部分，带着具体问题看比空着脑子看吸收率高得多。等三部分都过了一遍，再回头把项目里的测试补齐，这时候你会发现自己对代码结构的理解也跟着变清晰了，因为可测性本身就在逼你把逻辑拆干净。