发布于 2016-04-01 12:22:03 | 135 次阅读 | 评论: 0 | 来源: 分享
Dagger WebUI自动化测试框架
Dagger是网易杭州研究院QA团队开发的一个轻量级、运行稳定的WebUI自动化测试框架，主要基于Selenium及TestNg可以认为是对Selenium进行二次封装的一个框架（俗称 造轮子 ）。之所以把这个轮子开源出来，主要在于经过了公司内部多个项目的实践，也取得了不错的成效，因此，希望开源以后可以对大家有所帮助及参考。
前言
这2篇文章也收到好多网友的好评和提问，谢谢大家的支持。我大概总结了下提的问题：
因此我将结合这2点来进行本文的讲解。并且会有具体的sample。
咱们直奔主题：
增加开发效率、省去重复的简单体力劳动
首先new一个实例的过程是一个重复的简单体力劳动，dagger2完全可以把new一个实例的工作做了，因此我们把主要精力集中在关键业务上、同时也能增加开发效率上。
省去写单例的方法，并且也不需要担心自己写的单例方法是否线程安全，自己写的单例是懒汉模式还是饿汉模式。因为dagger2都可以把这些工作做了。
更好的管理类实例
每个app中的ApplicationComponent管理整个app的全局类实例，所有的全局类实例都统一交给ApplicationComponent管理，并且它们的生命周期与app的生命周期一样。
每个页面对应自己的Component，页面Component管理着自己页面所依赖的所有类实例。
因为Component，Module，整个app的类实例结构变的很清晰。
解耦
假如不用dagger2的话，一个类的new代码是非常可能充斥在app的多个类中的，假如该类的构造函数发生变化，那这些涉及到的类都得进行修改。设计模式中提倡把容易变化的部分封装起来。
我们用了dagger2后。
假如是通过用Inject注解标注的构造函数创建类实例，则即使构造函数变的天花乱坠，我们基本上都不需要修改任何代码。
假如是通过工厂模式Module创建类实例，Module其实就是把new类实例的代码封装起来，这样即使类的构造函数发生变化，只需要修改Module即可。
有个网友问过一个这样的问题，Module的构造函数也会发生变化，发生变化后，相应的new Module的类也发生变化，这就没有达到解耦的效果。首先解耦不是说让类之间或模块之间真的一点关系都没有了，解耦达到的目的是让一个类或一个模块对与自己有关联的类或模块的影响降到最低，不是说这种影响就完全没有了，这是不可能的。
解耦还有个好处，就是方便测试，若需要替换为网络测试类，只需要修改相应的Module即可。
具体的代码就不讲了，dagger2 sample地址，大家自行下载。这里重点说下dagger2对目标类进行依赖注入的过程，现在假设要初始化目标类中的其中一个依赖类的实例，那具体步骤就在下面：
步骤1：查找Module中是否存在创建该类的方法。
步骤2：若存在创建类方法，查看该方法是否存在参数
步骤2.1：若存在参数，则按从**步骤1**开始依次初始化每个参数
步骤2.2：若不存在参数，则直接初始化该类实例，一次依赖注入到此结束
步骤3：若不存在创建类方法，则查找Inject注解的构造函数，
看构造函数是否存在参数
步骤3.1：若存在参数，则从**步骤1**开始依次初始化每个参数
步骤3.2：若不存在参数，则直接初始化该类实例，一次依赖注入到此结束
以上是dagger2进行的一次依赖注入的步骤，其实这个步骤是一个递归的过程，并且在查找类的实例的过程中Module的级别要高于Inject，这概念在上一篇讲过。
下面在说下注意的几点
好了关于dagger2的所有的概念知识点到此终于结束了，希望能帮助大家，与大家共勉，有问题可以随时与我沟通。