Java单元测试的意义_关于java单元测试的作用和必要性？

我觉得不是 java 单元测试的必要性，而是工程的单元测试必要性，和语言无关。

当你的项目小的时候，简单的时候，当然单元测试没什么用。但是如果是写底层框架或者一些很大的项目时，单元测试对于提高生产力很有用。单元测试的好处是给人的，不是给机器的。

而且从程序设计的角度上看：单元测试可以让你更好的拆分程序为最小单元，帮助你更好的解耦。

用到单元测试则必不可少的会用一些自动单元测试框架，对完成工程的自动化测试很有用。

光说没什么意思，我们可以举例子：

场景一：你有一个底层的方法，业务逻辑上有几十上百个功能在使用这个方法。有一天，你想要给这个方法添加新的功能，添加之后到底好不好用呢？有没有 bug 呢？如果不用单元测试，你需要把几十上百个功能都跑一遍来验证方法的正确性。而使用单元测试的思路，则是对这个最小单元(即这个方法)进行测试，模拟可能的输入，看是否获得相应的输出，对参数的边界做判断等等，这就是一个简单的单元测试了，你可以不用任何单元测试框架，自己写就行。

场景二：你在写一个单元(方法)，而这个单元依赖其它的方法，而这个方法的执行结果是不受控制的，我们想要可控的测试，想要这个依赖的方法的几种执行模式都能按照预期进行，那么桩件(stub)和仿件对象(Mock)的思路就出现了 ，我们对这个依赖的方法进行仿造，使其执行后得到我们预期的结果，这样测试过程中即使出了错，也可以断定不是依赖方法导致的错误，为开发人员减少了一部分找 bug 的时间。现在大多数的单元测试软件、框架都有很方便的 stub、mock 接口，能很好的实现大多数测试需求。

场景三：扩展场景一的情况，你的程序架构是分层的，比如分了两层，上层是应用层，下层是驱动层。应用层依赖于驱动层的若干方法，而且依赖关系错综复杂。如一个应用功能依赖了十几个底层方法(底层方法间也有互相依赖的情况)，那么，如果这个应用功能有了 bug，那么是这个应用功能本身的代码的问题呢，还是依赖的这十几个方法的问题呢？还是说这十几个方法各自依赖的其他方法的问题呢？如果人工去找，累个半死。就算找到，修改好后，发现新的修改虽然修复了原有 bug，但又引起了其他 bug，那么这个新 bug 要继续找么？使用单元测试后，为驱动层的所有划分为最小单元的方法都编写测试，以最大程度(高测试覆盖率)保证这些单元可以独立运行成功，那么即使出了错，修改了某个方法，也能快速的定位到 bug 和修改后对程序的影响。

抛去一大堆理论，其实单元测试最直观的一个好处就是：当你在改了一个方法之后，跑一遍所有的单元测试，能快速的发现你有没有把程序改成傻逼。

你可能说这个项目都是你自己写的，你对这些程序了如指掌。但是加入别人接手你的项目，或者你接手了别人的项目呢？找 bug 时你会不会骂那个没写单元测试的人sb？很多的时候工程并不是一个人的玩具，需要为多人协作做一些妥协。

这么说理解了吗？

顺便这里推一下我自己的框架 WorkerA, 框架的核心部分 WorkerF 中就使用了 phpunit 做单元测试，帮我开发省了很多的时间。