单元测试

单元测试是什么
单元测试是针对程序的最小单元来进行正确行检验的测试工作。程序单元是应用的最小可测试部件。一个单元可能是单个程序、类、对象、方法。
单元测试的意义
减少bug
快速定位bug
提高代码质量
减少调试时间

减少bug
一个机器、由各种细小的零件组成，如果其中某个零件坏啦，机器运行故障。必须保证每个零件都按设计图要求的规格，机器才能正常运行
一个可单元测试的工程、会把业务、功能分割成规模更小、有独立的逻辑部件，称为单元。单元测试的目标，就是保证各个单元的逻辑正确性。单元测试班长工程各个零件按规格执行，从而保证整个机器运行正确，最大限度减少bug

提高代码质量
犹豫每个单元有独立的逻辑，做单元测试时需要隔离外部依赖，确保这些依赖不影响验证逻辑。因为要把各种依赖分离，单元测试会促进工程进行组件拆分，整理工程依赖关系，更大程度减少代码耦合。这样写出来的代码，更好维护，更好扩展，从而提高代码质量

快速定位bug、减少调试时间
如果程序有bug，我们运行一次全部单元测试，找到不通过的测试，可以很快的定位对应的执行代码。修复代码后，运行对应的单元测试，如果还不通过，继续修改，运行测试，知道测试通过
对于Android项目，要测试某个功能点，不用单元测试的话，必须运行在真机上、模拟器上，慢慢的debug找到问题点，运行程序到真机，快则半分钟，慢则几分钟。Junit只需在本地运行即可，就几秒的事。有时，写那个功能模块的员工已离职，APP出错，你根本不知道调试哪个类，如果离职的员工之前写了单元测试，运行一下立马就找到问题点了，单元测试大大减少调试时间，从而达到节约时间成本的效果

放心重构
重构、每个开发者都会经历，重构后把代码改坏了的情况并不少见。以往，写完一个框架，运行app，没什么问题，完事。由于最初的框架并不是你写的，可谓牵一发动全身，你改一个方法导致整个框架运行失败
如果你有单元测试，情况大不同。写完一个类，把单元测试写啦，确保这个类逻辑正确。写第二个类，单元测试。。。写100个类，道理一样，每个类做到第一点保证逻辑正确性。100个类拼在一起肯定不会出现问题。大可以一边重构一边运行APP，而不是整体重构完提心吊胆的运行

TDD测试驱动开发
Test-Driver Development，测试驱动开发，是敏捷开发的一项核心实践和技术，也是一种设计方法论。TDD原理是开发功能代码之前，先编写测试用例代码，然后针对测试用例编写功能代码，使其能够通过。由于TDD对开发人员要求非常高，跟传统开发思维不一样，因此实施起来相当困难。
测试驱动开发有好处也有坏处。因为每个测试用例都是根据需求来的，或者说把一个大需求分解成若干个小需求编写测试用例，所以测试用例写出来后，开发这写的执行代码必须满足测试用例。如果测试不通过，则修改执行代码，知道测试用例通过。
好处：通过测试的执行代码，肯定满足需求，而且有助于与接口编程，降低代码耦合度，也极大降低bug出现几率。
坏处：投入开发资源、由于测试用例在未进行代码设计之前写，很有可能限制开发者对代码的整体设计、可能引起开发人员的不满情绪，我觉得这点很严重，毕竟不是人人都喜欢单元测试，尽管单元测试会给我们带来相当多的好处

总结
单元测试确实会给我们带来相当多的好处，但不是立刻就能体现出来。正如买重疾保险，交了很多保费，没病没痛，十几年甚至几十年用不上，最好就是一辈子用不上理赔，身体健康最重要，单元测试也是一样，写了可以买个放心，对代码的一种保障，有bug尽快测试出来，没bug更好。总不能说：写那么多单元测试，结果测不出bug，浪费时间吧