不要被单元测试拖累！不要被单元测试拖累！！不要被单元测试拖累！！！
单元测试是针对系统最小单元（一般是函数、也可以是类或者模块）来进行正确性检测。我们使用单元测试的目的是优化代码质量、提高开发效率，不要一味的追求100%代码覆盖率，没有意义。
如果你写好了代码，再写单元测试，那一定是为了单元测试而单元测试，你一定感受不到它的好处了，或者你会说我有了单元测试，后期的重构或者改造我将更自信（我不只一次听到这种说法，单元测试验证的是最小单元，它们太容易被改变了，大多数情况下你重构后的代码的单元测试大多数要重写）。
我认为单元测试的好处在前期、甚至业务开发完成后它对应的单元测试我不会再维护，直到我确实用到了他们（调试bug、重构业务）。当然，长期的维护单元测试的好处是显而易见的，当业务出现变更，只要跑一下单元测试，我将变得无比自信。但是它的维护成本太高了，基本等于业务的维护成本，我不能被单元测试拖累！！！
如果，你写代码之前有设计的习惯，比如在草稿纸上比比画画，或者提前在脑子里面构思清楚。我见过有同事写代码前一定会发呆一会，一脸严肃，时而皱眉沉思、时而龇牙咧嘴，我知道他有一个好习惯。如果你也是这样，不妨使用单元测试，来代替你的草稿纸或者你的龇牙咧嘴，来使用代码来比比画画呢？比如像下面这样，很随意的写写：
第一阶段，先使用伪代码来理清逻辑思路和业务。这个阶段可以省略，不过我还是建议你刚开始的时候可以现尝试一段时间，就是比比画画，怎么写都行，没有规范和格式的约束，比在脑子里面来构思要爽多了。
现在，我们需要写真正的代码了，因为这个阶段还没办法写业务代码，所以我们需要先定义出抽象。如下图：
设计即抽象，而单元测试会指导我们定义出抽象来，上图中的接口不是先设计出来的，而是在写单元测试的时候，缺少什么，需要测试什么，我就把它定义出来。面向抽象编程，不是为了抽象而抽象，我们不是基于已有的实现类，强行对它进行抽象。而是，我们需要用抽象构建出蓝图，抽象就是前期比较粗的线条，在这个基础上，后面的细节再慢慢完善。
现在有了抽象，后面需要做的就是让别人把它实现出来，这应该并不困难，只要写业务代码，跑单元测试，不通过的话，改代码再跑测试。通过的话，再接着开发下一个函数实现。这节约了大量的运行调试时间，在这个阶段你应该感觉很爽才对。
另外View层仅仅在本地java虚拟机中是无法测试的，不过因为view层确实比较简单，仅仅只是提供参数、或者基本能力，这部分代码不进行测试问题也不大。这其实也正是google推出MVP的初衷，将View层抽象解耦出去，来实现高效的单元测试。
下面放出，单元测试代码，因为没进行调试，可能有地方会有问题，但大致流程是正确的：
LoginModel.kt
LoginPresenter.kt
如果你会用单元测试，那么你一定爱用单元测试。
