什么是单元测试
单元测试是用来对一个模块、一个函数或者一个类进行正确性检测的测试工作
单元测试从长期看可以提高代码质量、降低维护成本、为重构提供质量保障。但是从短期看加重了工作量，对于处在项目紧张的人员来说会增加很多负担。
通过与朋友讨论和自己经历发现有几个原因使得大家对单元测试很排斥或者不感冒。
- 我做了单元测试啊 单元测试描述是从软件引入，同时与硬件验证分级有一些冲突，所以产生一些理解的偏差，验证中通过遵循的为IP、subsystem、soc三层验证，单元测试属于ip验证下，这些都属于从功能层面看是否实现，而非关心代码是否合理清晰，可扩展、可复用、可测试等。
- 通过集成随机测试能够抓到bug，为什么要写单元测试 随机测试是在验证环境被较多使用的技术，在过去一些年发挥了很大的作为，在未来的很多年内也会继续发挥不可替代的价值，但是随机测试一个很大的问题是发挥不稳定，且需要消耗较多的时间进行收敛，如果做定向在较大模块中又显得不那么靠谱。 所以单元测试被限定在很小的一个范围内，用来保证基本单元的正确性，作为多级复用的最底层而存在，即螺丝钉的质量要有保证。 我们做的很多重构都是基于螺丝钉的，这样在单元测试/原子功能测试这块就能进行质量保证，不仅花费时间短，而且可以通过迭代有效收集测试用例，保证之前出现的问题不会再出现，作为一个80%完备度的快速测试集。
- 项目前期还能做做，后期紧张单元测试就被放下了，且都到了集成测试阶段，单元测试也没什么用 个人觉得没有考虑好单元测试到底有什么作用，且分层验证没有做的特别好，使得后期价值不断缩水。如果把验证环境的单元测试也考虑进去的话，后期被放下的概率也会变小。
- 编写单元测试不在kpi考核范围内，浪费时间还可能使得自己主要工作没完成 这是一个先有鸡还是先有蛋的问题，是否愿意用长期价值换取短期价值，且单元测试能够很好发现可测性的问题，这对后期系统可扩展有较大的好处，有些事务做了会慢慢发现好处。
单元测试要写多细 个人觉得不是所有的都要写单元测试，也需要考虑项目进度的问题，需要在进度和完备度做一个折中。
- 在规划阶段，大部分还停留在写架构、写独立模块的时候，验证的验证就可以进行了，用以保证验证本身质量，且测试用例也是一个很好的活文档，可以帮助理解，以及怎么用。
- 在coding阶段，容易出错的、不易理解的都可以使用单元测试来帮助我们。
- 公共代码、验证库、核心代码等都需要高质量的维护，任何的改动影响面都会很大，有完善的单元测试时很有必要的，尤其是验证的测试代码，这个做的还是很少的，对保证验证的代码在多次修改中不出问题提供了有效的保障，即使有增加单元测试也会保证该问题不会再次出现。
何时写单元测试 每个人都有不同的理解，有说在代码前的，有和代码一起的，也有代码后的，个人是在代码前进行测试规划，完成一个简单的小功能，增加一个测试，且将之前的测试跑过，这样新增代码少，debug效率高，当然这只针对验证自己可控的验证部分，与设计交互部分需要大家协商解决。
为什么要写单元测试
- 让我们对代码有信心 单元测试的目的是解决小问题，每次修改后测试都通过至少可以告诉我们之前发现的问题没有因为修改再出现，将能暴露的问题在最短时间内暴露。 在功能/集成侧发现的问题同样可以通过增加单元测试来保证，提高发现效率。
- 为重构质量提供保障 看着代码比较差，想改，改了后要怕出问题，设计debug半天发现是验证的事情，单元测试可以充当保护神。 如果这件事情在后期做可能就不那么保险，设计人不一定有那么多耐心，如果在前期一片混沌时将单元测试加入，就能让我们在后期放开手脚，放心的改吧。
- 通过单元测试快速熟悉代码 通过阅读单元测试就可以知道代码如何使用，怎么工作，包含哪些业务。
- 通过单元提高可测性、可扩展、可复用能力 如果将功能写到1000行的函数中容易测试么，想加个功能应该也不容易，想被其它模块用也不现实，一般来说可测性与可扩展和可复用是一同出现的，当我们通过单元测试满足了可测性，就可以被动提高代码的可扩展和可复用能力。
- 将bug消灭在过程中 一个bug隐藏的时间越长，修复的代价越高，对于任何要进库的代码进行单元测试也是对一起工作的小伙伴负责，当然这一步可以隐藏在自动化流水线中。
