• 在项目中写单元测试的要求和建议，虽然从开始工作就一直要求自己去写，但是实际中很少能坚持下去，尤其是需求变化很多的项目，维护的成本真的很高。而且一直的crud，感觉很少需要这种。但是最近发现一些需求不写单元测试，对小变动的需求的成果是没有办法保证的。如在原有的算法策略上增加一个策略，但是最终想要的结果和之前一样（如商品的复制、下载等），这个时候一个好的单元测试的用例，会减少后面这种的重头再来一遍测试的必要，加速提交成果。

1.单元测试是必要的，因为底层代码如果因无法保证而会导致上层代码的崩溃，从而引起整个项目的崩塌，重构很是麻烦。

最根本的，你要回答的是这个问题『这段代码达到我的目的了么？』。也许就需求而言，代码所做的是错误的（ps:这个也是我经常的接口，因为需求经常性变动，导致代码本身的业务逻辑估计都是错误的，所以重构是必然）。但是那是另外一个问题了。你要的是代码向你证明它所做的就是你所期望的。

2.单元测试不能只是编写一个测试，让所有的代码重头到尾跑一遍就ok，要考虑所有的情况

ps：目前我都是用postman去跑边界 ，但是这个是在经验的情况下去测试问题，但是终有一天，经验是没法使用到的。比如上次的消息问题，还是有很多情况没有考虑的，但是大都是从业务上给规避了。这次的电子发票的事情需要仔细考虑单元测试的情况，因为更高级的公司，也很看中自己的单元测试，不是所有测试都是扔给测试人员去黑盒测试和白盒测试的

3.我们希望能够依赖于所编写的代码，并且清楚的知道这些代码的功能和约束。

如函数不必要接收一个空值，那么可以在注释中增加约束，如果接收到空值就会抛出异常.单元测试的另外一个好处就是可以帮助你充分了解代码的用法，除了像执行的文档，在各种条件下调用代码时你所能期望这段代码完成的功能

项目成员能够看到你的测试用例，如果其他成员发现一个你没有考虑到的测试用例，那么他就知道你的代码可能并不支持这个用例