作为开发程序员，大家可能对单元测试存在如下误解：
- 那是测试同学干的事情。
- 单元测试代码是多余的。 汽车的整体功能与各单元部件的测试正常与否是强相关的。
- 单元测试代码不需要维护。一年半载后，那么单元测试几乎处于废弃状态。
- 单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。
如果你存在以上的一个两个甚至全部的误解，请大家开始思考。单元测试可以帮到我们什么？首先，我们应该清醒的认识到自己写的第一版代码，肯定是存在这样或者那样的问题。单元测试是个工具可以检测我们写的代码是否符合之前的预先设计。我之前有提过，开发就是设计。你写的每个方法，其实都有个设计过程。而单元测试就是把你的设计过程进行显性的固定下来。还有个场景，当我们接到某个需求，需要改动之前别人写的一个方法。你肯定会想写debug一下，走一下这个方法的逻辑，和最后的结果。一般这样的方法质量都不会高的。要不我干嘛还需要debug?直接看不就行了。但是我们确实会遇到这样的历史债务代码。这个时候，如果它有个对应的单元测试方法就好了。我可以在这个方法的保护下重构优化原来的债务代码。单元测试是小步重构的保护机制。那么写单元测试代码，需要注意什么呢。请看下面开发手册的内容。
单元测试.jpg
这里请大家注意单元测试的独立性和可重复性。不要把自己写的测试代码写的和业务代码一样。我认为，单元测试代码和业务代码应该是相辅相成的，缺少哪一个，你的编码任务其实都是不完整的。另外，单元测试一定要用断言。推荐大家使用AssertJ。它是流式断言api。很好用哦。
那么请大家开始写自己的测试方法吧！
网友评论