单元测试以及dagger的使用

最近对测试比较敏感,因为涉及了代码重构,虽然我是很有自信的一个人,但是过度严谨的强迫症很多时候让我很尴尬.

所以还是希望面对源代码有一定的测试代码,以方便验证代码重构之后的正确与否.

所以,游戏开始了.经过了2天的琢磨,终于对android单元测试有了初步的了解.个人看代码,还是很不喜欢记忆比如说,具体的方法的用法啊,什么这个设计模式到底叫什么啊...等等等等,所以很多时候还是很尴尬的,因为就是有一大堆人,总是问我这些= =

说说下文中引用的博客的测试精髓吧,单元测试的精髓,经过我长达两天的钻研,在于模拟,众多的可测试框架名称中就含有mock一词,其意图也是很明显,就是单纯使用一个替代的类来解决源代码中类与类之间的耦合关系,比如,模拟接口返回结果,变量等等.

OK,单元测试就说到这里了,很简单有没有,但是这就是事实.

然后就是dagger的问题了,dagger2android目前我并没有详细地看过,但是就当前对于dagger2而言,dagger2是一种很好的解耦方式,相对于AOP的面向方法的依赖注入,dagger2更倾向于面向对象的依赖注入.这样说其实有一些欠妥当的,因为对于java面向对象的思想下,万物皆可为对象,哪怕他是方法.

dagger的表观使用思路就是这样(我还真的是挺少亲自画画呢= =,因为懒)

在使用者的角度来看,一般通过注解的方式实现依赖注入,annotationPrecessor进行编译器的注解处理

我更倾向于dagger是一种注射的过程,注射的过程中也就是使用针筒将药物注射到相应的位置

其中@inject标记的是药物本身,@component标记的是针管,他连接着储存着药物和人体,而@module标记的是病房,收纳的是container患者,患者身上有需要主要注射的患处,这些患处需要@inject药物的填入

而dagger就是将药物注射到患处的注入过程

在具体实现方面,就存在药物生产商,和实际上充当针管的injector的两个角色,在下述的博客中就有着很好的描述,这里就不多加赘述了.

android单元测试

https://github.com/simplezhli/AndroidUT

dagger基础以及dagger_android

https://blog.csdn.net/mq2553299/article/details/77485800

https://blog.csdn.net/mq2553299/article/details/73136396