对于前端来说，测试主要是对HTML、CSS、JavaScript进行测试，以确保代码的正常运行。
常见的测试有单元测试、集成测试、端到端（e2e）的测试。
单元测试：对程序中最小可测试单元进行测试。我们可以类比对汽车的测试，在汽车组装之前需要对零件进行测试，这种情况下就和单元测试一致。只有零件正常才会进行下一步的组装
集成测试：对多个可执行单元组成的整体进行测试。类比于汽车的测试，就相当于测试发动机之前，需要把发动机所需的零件组装在一起对组装后的发动机这个整体进行测试。
端到端的测试：从服务端到客户端的测试。这种测试是对服务端和客户端组成的整个系统进行测试，它是能够执行完整流程的测试。
既然知道了有这些测试种类，接下来就说说这些测试应当如何实现。
什么是前端单元测试？
- 为检测特定的目标是否符合标准而采用专用的工具或者方法进行验证，并最终得出特定的结果。
- 对于前端开发过程来说，这里的特定目标就是指我们写的代码，通过写的测试用例检查的结果展示测试是否通过或者给出测试报告，这样才能方便问题的排查和后期的修正
- 对于给定的输入，单元测试检查结果。通过及早发现问题并避免 bug 回归，它可以帮助我们确保代码的各个部分按预期工作。
为什么需要单元测试？
前端的单元测试在很多人看来都是一个可有可无的东西，理由一般有下面几条：
- 写单测比较费时，有这个时间不如多做几个需求
- 测试在验收的时候对页面的功能都会操作一遍，写单测相当于做无用功
- 后端提供给前端的接口需要保证质量，因此需要做单测，但前端很少需要提供接口给其他人
其实，我大体上是同意以上观点的。在大部分的情况下，如果公司的业务不复杂，是完全没必要做单测的。但如果涉及到以下几个方面，就要考虑是否有必要引入单测了：
- 业务比较复杂，前端参与的人员超过3人
- 公司非常注重代码质量，想尽一切办法杜绝线上出bug
- 你是跨项目组件的提供方 你在做一个开源项目
单测的好处：减少bug，提升代码可读性可维护性，为系统重构做铺垫。
单元测试覆盖率
含义：软件测试中的一种度量指标，指在所有功能代码中，完成了单元测试的代码所占的比例。
具体分为行级、分支级、方法级等不同级别。
它可以从一定程度上衡量我们对代码测试的充分性。原则上我们追求的单元测试覆盖率目标是100%，但业务场景多的情况几乎是不可能。
平台类项目，核心复杂功能尽量覆盖率做到最高，业务类的酌情处理。
目标覆盖率：
行覆盖率（line coverage）：表示是否每一行都执行 80%
函数覆盖率（function coverage）：表示是否每个函数都调用 100%
分支覆盖率（branch coverage）：表示是否每个if代码块都执行 80%
语句覆盖率（statement coverage）：表示是否每个语句都执行 80%
单元测试框架
实现单元测试的库和框架有很多，推荐选择jest
优点：
- 比较新
- 基础好
- 速度快：支持单模块测试，减少测试代码
- API简单：容易上手
- 隔离性好：文件之间相互独立
- IDE整合：vscode插件
- 多项目运行：提高效率
- 覆盖率：导出测试覆盖率
使用jest进行单元测试比较简单，因为Jest提供了很多方便的API供开发者使用。
总结
前端可以写单元测试吗？
答案是前端可以写单元测试，但是意义不大。 前端项目中如果有一些基础类、方法，可以编写测试。 但是组件、视图不太需要，性价比太低。 业务代码吗？ 鬼才做。 每个月都在改，测试代码每天写到天亮都写不完。
项目里面可以不写单元测试，但是不代表前端可以不懂单元测试，下篇文章讲一下怎么用jest
)
