背景
工作中，不止一个同学提出过这样的问题：我们项目要写单元测试吗？
这个问题很宽泛，因为单元测试也只是我们解决问题的一种手段、工具，本身没有好坏、要不要写，抛开具体场景谈工具，都是耍流氓；
那么我来谈一谈，就针对我所做的工作，是否需要单元测试；
单元测试
是什么
单元测试，如果我们写了一个类的方法，那么我们就需要针对这个方法去写一些测试cases，以保证我们提供的方法正确性；
那么时间问题来了，如果我写的是POJO，那么其中的setter、getter方法要写单元测试吗？本来这些方法逻辑就极其简单、通过工具都是自动生成的，有些框架如lombok的使用直接能让我们免写手动写setter、getter；
即使有些逻辑复杂的方法，我们写的单元测试，但是也不一定能保证最终功能测试、集成测试、压力测试的时候管用啊；
带着这些问题，我们继续往下看。
能做什么
既然是测试，当然是为了保证质量，比如我写了一个方法，可能存在十种调用场景，我写了两种场景的调用cases，那么就能保证这两种场景的调用逻辑；
这么说我们都应该去写单元测试了吗？
我们最终是要保证开发的功能是正确的，但是只写单元测试其实是不能保证我们的功能最终正确性，那么我们直接针对提供的服务、功能写测试是不是就可以了，比如我提供了一个生成订单服务，我对这个生成订单服务做测试，是不是更好？
个人观点
个人经验来看，做业务后台开发，写功能测试的收益要比写单元测试的收益更高，这里的收益主要是指的投入时间与产出，重点关注对外提供的功能是否运行正确，功能测试时也会走到单个方法的执行处，虽然不一定所有方法都能覆盖到（这个主要看测试用例全不全）；
目前我们做的不少业务都是有时间限制的，其实也就是成本控制，所以如何在有限资源（时间、人力等）下保证业务的快速上线、试错，才是王道，天下武功、唯快不破；如果说写单测能达到目的最大化、那么果断写单测，如果写功能测试能达到目的最大化、那么果断写功能测试；
一切选择都是权衡，付出了什么便会得到另外一些，看到一些新人经常会问写不写单测，其实他们从来就没写过单测，那么我的建议是，先抽空认认真真写几个单测，再来谈要不要的问题；可能是前些年TDD、XP被一些人鼓吹起来，大家不管新手老手都听到了单元测试这个词，好像没听说过走在路上都不好意思跟别人打招呼一样，技术都是工具，在适合的场景下去选择便好，没有万能的工具、没有银弹。