测试，是现代软件开发过程中一个必须的组成成分，任何的产品想要真正推向市场，都必须经过一轮又一轮的测试，以及来保证产品的可用性，增强团队对于产品的信心。 而单元测试，则是其中的一个组成成分，软件行业发展到今天，它的角色也越来越重要，逐渐成为最基本的测试实践之一。

但据我所了解到的情况来看，写单元测试在很多的人和团队的眼中更像是一种“政治正确”。 看见大家都在做单元测试，社区都说要写单元测试，技术负责人一看，“咦，不行，我们不能落后，我们也要写”。于是团队成员在一种极其不情愿的情况下写起了单元测试，这样的单元测试，难怪大多数开发人员觉得是负担。

所以，在进入正题之前，我想先简要的阐述一下我对于单元测试的观点，即为什么要做单元测试？

PS：本文使用的测试框架为 Jest + React testing library。但将会跳过这些框架的语法介绍部分，更偏向于介绍如何写的的实践部分。要阅读文章包含的代码部分，读者最好对 react+javascript 有基本的掌握。

WHY

单元测试可以提高代码和软件的质量保障，这一点应该没有人会反对。但真正进行推行的时候，“没啥作用”，“浪费时间”，“又是工作量” 这些声音却总是不绝于耳。

上面提到单元测试如今逐渐成为一种行业标准和政治正确，但总还是有团队在执行的时候“将在外君命有所不受”，一边说着：“要写真正有用的测试，作用不大的测试应该砍掉”，一边理所当然地看心情写测试。最终的结果往往就是最终的项目基本没有覆盖单元测试。

要克服这个心里障碍，我们就要弄清楚我们到底是为什么要写单元测试。 单元测试真的是浪费时间么？ 肯定不是， 从一个最底层开发者的角度， 假设你开发了某一项功能，将之发布的前提是手工测试通过。而后来这个模块又出现了一个新需求，因为做这个新功能你对原来的代码有一些改动，于是在发布前你除了测试了新功能是否有问题外，还必须手工测试一下以前的功能是否受到的影响。然后这时又来了一个新功能。。。你逐渐发现你每次要测试的东西越来越多。 后来某一天，来了一个新的架构师，他觉得你们之前的编码臃肿而”丑陋“，”为了便于未来的扩展“，他让你重构你的代码。这时的你是绝望的，因为没有单元测试保证，你的任何改动都需要进行手工测试保证无误，于是最终你选择了跑路。