这是我在知乎上一个问题的回答
    其实广义的来说, 自动化测试指的是:

    自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。 通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。 在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

    当然这也不是一个仅仅局限于前端的词, 我们希望讨论的, 是 ‘前端开发人员/测试人员’ 实现自动化测试的方式, 这主要有两种: 单元测试(unit test) 和端到端测试(e2e test)

    首先单元测试是主要面向程序员的, 不论怎么讲, 单元测试都是十分必要的, 但像题主提到的 国内很少有文章阐述这些 也确实存在, 其原因无非以下几种:

    1. 懒; 写单元测试是一件比较枯燥的事, 而且写好单元测试也是一件难事, 大部分程序员不愿意写单元测试都是因为 有写测试的时间还不如多写几个模块呢 , 理论上确实是这样, 但今天埋下的坑, 总会有一天 debug 的时候找回来, 坑可能会迟到, 但永远不会缺席;
    2. 开发周期短, 没有时间沉淀; 对于这种情况, 我会建议 “测试不该在开发之后写, 应该在功能实现之前, 至少是同时”, 如果在功能实现之后很长时间, 或者你比较闲的时间去写测试, 那么你写的用例会比较差;
    3. 项目很小, 或者迭代周期太快; 如果真的很小(逻辑简单), 那么确实不太需要写单元测试, 甚至也不需要自动化测试, 也可以针对几个核心的纯函数写几个简单的用例; 如果是项目迭代周期过快, 说明还是很有必要做测试的, 尤其是在迭代过程中, 积累了之前的经验, 测试用例写起来也会更加全面, 更加得心应手;

    其次是 e2e 测试, 指的是把我们的程序当做是一个黑盒，我不需要懂你内部是怎么实现的，我只负责打开浏览器，把测试内容在页面上输入一遍，看是不是我想要得到的结果。这部分应该是 QA 去做( 有时候也让用户去做 2333), 是面向用户的, 相比 unit test, e2e test 也有十分重要的意义:

    1. 是从用户角度出发的; e2e 测试除了能发现功能性问题, 还能发现程序易用性的问题, 尤其是在一些重交互的应用, 高效实践端到端测试相当于吃了一颗定心丸;
    2. 更加贴近 自动化测试 的概念; 相比于单元测试, e2e 测试跟项目耦合程度更低, 而且期望是模拟人操作来做测试, 很好的实践了 自动化 这一概念;

    最后呢, 发现回答有一些偏题, 往回拽一拽, 说说为啥 “为何国内的前端对自动化测试好像不是很看重?”

    1. 真的不看重吗? 其实并不是的, 纵览 GIthub 上国内比较大型的开源项目, 自动化测试/持续集成 都已经应用很长时间了, 而且对于开源项目来说, 测试覆盖率也是其项目可信度的评估指标之一, 对于公司内部项目/非开源项目, 据我了解, 测试也是能写则写, 不会存在不重视这一现象;
    2. 为什么你觉得文章少; 其实我觉得不止自动化测试相关的文章少, 编程其他领域的文章也很少, 而且在当前优秀测试库层出不穷的时代, 降低了写自动化测试的成本, 基本上一个没经验的开发人员看完官方文档就能写出来比较规范的测试代码, 所以我觉得要是写测试相关的文章, 也应该多多分享些 “经验” 而非 “指南”;
    3. 写测试不是一件难事; 包括 UI 测试, 尤其在一些数据驱动(flux, pure component 等) 的思想影响下, 可以化简为一个等式: UI = render( state ) , 其中 render 是纯函数, UI 测试就能转化为 state 测试, 对于数据的测试, 我们有无数种方式, 其次的, 随着 HeadlessChrome/Puppeteer等 的发展, 相信 e2e 测试也会迎来一个飞跃;