为什么使用依赖注入_TestNG的依赖注入详解和使用场景分析

最新推荐文章于 2022-03-04 17:23:38 发布

weixin_39902107

最新推荐文章于 2022-03-04 17:23:38 发布

阅读量307

点赞数

文章标签：为什么使用依赖注入依赖注入的三种方式接口无法注入

点击上方蓝色字体，关注我们

摘要

软件设计方法中的依赖注入是比较晦涩的概念，采用这种方式能够解耦类之间的依赖，提高系统的灵活性。作为当今最为流行的自动化测试框架TestNG，为了增强系统的灵活度，为我们提供了依赖注入的实现，给我们提供了很大的便利。作为TestNG使用者，我们可以不用理解过于晦涩的依赖注入的概念，而很便利的得到由此带来的好处，甚至我们可以不知道这种设计是依赖注入。

本文从依赖注入的概念说起，首先给出依赖注入的简介和入门级示例。之后介绍TestNG的两种依赖注入使用方式：原始依赖注入和外部依赖注入。对于每种方式，都给出简介和示例，同时对何时使用该种方式也做了初步的建议。本文的目的，一方面说明TestNG依赖注入设计的来源和使用方法，从而深入理解TestNG，避免囫囵吞枣的使用，提高遇到问题的解决能力；另一方面，通过实例说明TestNG依赖注入的应用场景，防止理论无法落地实践，毕竟能够解决实际问题的方案才是有价值的。

一、依赖注入简介

1.1 依赖注入简介

　　详细介绍依赖注入需要很大的篇幅，由于本文不是专门介绍依赖注入，所以这里只做简单的说明。依赖注入，英文是Dependency Injection，简称DI，是软件架构设计中的一种技术。简单理解就是我们定义的类(A)如果需要依赖其他的类(B)来完成工作，通过依赖注入的设计，使得类B的实例化不在类A中进行，而通过第三方的实例化后传递给类A，从而实现解耦的目的。这个第三方就是DI容器，也称DI框架。简单的说就是类之间的依赖关系，不再类之间直接引用，而是通过DI容器进行适配管理。

　　这样做的好处就是实现解耦，即类A虽然调用了类B，但类A要与类B的实现解耦，这与设计模式中的依赖倒转原则一致：高层模块不依赖于底层模块，他们都应该依赖于抽象，抽象不应该依赖于具体实现，具体实现应该依赖于抽象。

　　1.2 依赖注入示例

　　依赖注入的实现方式有很多，常用的有三种方式：构造方法注入(constructor injection)，setter方法注入(setter injection)，接口注入(interface injection)。下面以构造方法注入作为示例，说明依赖注入的实现机制。

　　1.2.1 不使用依赖注入

　　考虑这样的需求，一个测试执行类，在测试完成后需要生成Html格式测试报告，一个简单的实现如下。

　　HtmlReportService实现如下。

　　这是没有使用依赖注入的情况的实现。由于在TestRunner类中直接使用了具体的报告实现类HtmlReportService，所以当HtmlReportService发生变化或者需要增加其他类型报告服务时，都需要修改TestRunner代码。两个类的没有解耦。

　　1.2.2 构造方法依赖注入

　　对TestRunner类做如下修改，将HtmlReportService的引用修改为对接口的引用，同时不再需要TestRunner本身实例化报告服务，修改为通过构造法方法传递引用。具体代码如下。

　　HtmlReportService实现变更如下。

　　IReportService实现如下。

　　通过依赖注入的方式，完成了TestRunner与HtmlReportService的解耦，在确保IReportService接口能够兼容旧版本的的情况下，修改HtmlReportService实现，或者增加IReportService实现类，对TestRunner都没有影响。需要修改的是依赖注入的组装过程。

　　当然可以通过更灵活、强大的第三方框架完成依赖注入的组装，就是上文提到的DI容器。我们平常所说的依赖注入学习，除依赖注入本身的概念和知识之外，更重要的是依赖注入框架的学习。上述例子可以通过Spring框架进行组装。

文章选自《51测试天地》第五十二期电子杂志