CN104182346A - 一种适用于osgi的检测框架 - Google Patents

Abstract

本发明提供了一种适用于OSGI的检测框架，该框架在OSGI环境中运行基本的Junit单元检测，建立单独的检测模块，把业务逻辑代码和检测代码完全分离，为后续项目构建和集成提供前提便利条件，检测运行环境收集所有检测模块里的检测用例，以集合的形式，对所有的检测用例进行汇总，方便检测的整体运行。

Description

一种适用于OSGI的检测框架

技术领域

本发明涉及一种软件构件化设备，具体涉及一种适用于OSGI的检测框架。

背景技术

OSGI(Open Service Gateway Initiative)技术是面向Java的动态模型系统，OSGi的主要职责是让开发者能够构建动态化、模块化的Java系统。使用OSGi后，应用的过程就像搭积木一样搭建，例如，对于一个正在运行的系统，其中一个模块要使用日志服务，但是目前的系统并没有提供日志服务的模块，此时可以直接从网上下载实现日志服务API的模块，然后动态安装此模块，随后其他要使用日志服务的模块就可以使用了。

在OSGi环境里，针对业务逻辑模块，编写专门的检测模块，这样可以做到检测代码和业务逻辑代码完全分离。提供包含Junit检测框架的检测环境模块收集各个检测模块的检测用例，并且为检测模块提供Junit运行环境支持。

OSGi框架中每一个模块都是一个Bundle，Bundle从形式上讲是在META-INF目录下的MANIFEST.MF文件中加入了OSGi特定描述的一个jar包。Bundle的生命周期被OSGi框架管理。

目前业界广泛应用的OSGi运行框架，被称为Java语言的动态模块系统。它为模块化应用的开发定义了一个基础架构，它使用Bundle的概念把复杂的应用程序模块化。Bundle的生命周期由OSGi运行框架维护，并且Bundle之间是相互依赖的，这也决定了加载Bundle时的顺序。在带来松耦合互相依赖的同时，也产生了严格的访问控制，只有少数的接口能够被其他Bundle访问到，传统的单元检测无法在OSGi环境里运行。在检测中，经常需要对Bundle中非公开的包或方法进行检测。并且检测代码如何与业务逻辑代码分开也存在问题。

OSGi运行环境经常是由十几个或者几十个Bundle组成，如果针对每一个Bundle都写好检测代码，那么单独运行每一个检测用例也很麻烦，需要手动去执行每一个TestCase。如何把所有的检测用户汇总在一个专门的检测Bundle里面，能够一次性运行所有的检测，也是面临的一个问题。

所以需要针对OSGi特点，提供一种单元检测框架，该框架可以在OSGi环境中运行基本的Junit单元检测，把业务逻辑代码和检测代码完全分离，并且通过专门的检测运行环境对所有的检测用例进行汇总，方便检测的整体运行。

发明内容

为了克服上述现有技术的不足，本发明提供一种适用于OSGI的检测框架，该框架可以在OSGI环境中运行基本的Junit单元检测。建立单独的检测模块，把业务逻辑代码和检测代码完全分离，为后续项目构建和集成提供前提便利条件。检测运行环境收集所有检测模块里的检测用例，以集合的形式，对所有的检测用例进行汇总，方便检测的整体运行。

为了实现上述发明目的，本发明采取如下技术方案：

一种适用于OSGI的检测框架，其包括多个业务模块、多个检测模块和检测运行环境模块。

本发明提供的优选技术方案中，编写业务模块的元数据描述配置文件，将业务模块中需要进行检测的接口以osgi服务的方式对外导出。

本发明提供的第二优选技术方案中，所述检测模块分别引入osgi服务，并编写检测用例。

本发明提供的第三优选技术方案中，所述检测用例确保方法接收预期范围内的输入，为每一次检测输入返回预期的输出。

本发明提供的第四优选技术方案中，每个检测模块中，都新建Junit检测组件，运行所述检测模块里所有的检测用例，每一个检测组件都声明一个Spring Bean。

本发明提供的第五优选技术方案中，在Spring配置文件里引入所述Spring Bean，新建一个检测集合组件，实例化检测模块中的检测组件，遍历和执行所有的检测用例。

本发明提供的第六优选技术方案中，在写检测代码的过程中，若会出现检测业务模块方法依赖的业务模块没有完成的情况，为了不影响本业务模块的单元检测和能够和其他模块隔离，使用Mock对象来模拟协同模块预期的行为。

本发明提供的第七优选技术方案中，所述多个业务模块之间具有独立和依赖两种关系。

本发明提供的第八优选技术方案中，所述检测框架适用于OSGI环境与Maven持续集成环境结合在一起，进行持续集成检测。

与最接近的现有技术比，本发明的有益效果：

本发明提供的技术方案使用EasyMock来模拟其他模块的功能，在明确的知道其他模块接受的指令和返回的结果的情况下，通过这个方式可以实现对模块之间逻辑调用的检测。由于这种方法并没有实际调用其他模块，所以待依赖模块开发完成之后，可以使用加载依赖Bean的方式对依赖的模块功能进行调用，实现模块的单元检测部分。

本发明提供的框架中结合Mock模拟的思想，可以将本模块与其他依赖模块完全分隔开，这样检测不受协同模块开发进度的影响；另一方面通过与Mock对象协作，可以获得一个孤立的检测环境。

附图说明

图1是框架的整体架构设计图

图2是检测方案的功能分布图

具体实施方式

下面结合附图对本发明作进一步详细说明。

假设现在运行环境里包含两个业务模块：A和B，且A、B之间有依赖关系。检测框架的具体设计如下：

(1)、编辑两个业务模块的元数据描述配置文件，将两个模块中需要进行检测的接口以osgi服务的方式对外导出。

通过注册osgi服务，检测模块可以在OSGi容器里引用这些服务用来进行单元检测。

(2)、新建检测模块：TestA和TestB，分别引入上一步中的osgi服务，编写检测用例。

检测用例确保方法接受预期范围内的输入，并且为每一次检测输入返回预期的输出。

(3)、在检测模块里，新建Junit检测组件(Test Suite)，涵盖检测模块里所有的检测用例。

通过这样的方式，为每一个模块内的检测用例提供一个整体对外接口，这样可以通过调用这个接口一次性运行所有的检测用例。每一个检测组件都声明成一个Spring Bean。

(4)、新建检测环境模块，在Spring配置文件里引入Spring Bean。新建一个检测集合组件(Test Runner)，通过实例化其他检测模块的检测组件Bean，可以遍历和执行所有的检测用例。

这里需要在OSGi环境里集成Spring环境，这样才能正常定义和实例化Bean。在实例化Bean的过程中，可以使用ApplicationContext通过ClassPathXmlApplicationContext读取依赖的xml文件来实现。对于实例化过程中一些可以忽略的空指针问题，可以使用Mock来模拟预期行为。

通过类的名字和包名注册Bean并发布为OSGi服务。在写检测代码的过程中，可能会出现检测方法依赖的模块还没有完成的情况，此时为了不影响本模块的单元检测，也为了能够将本模块与其他模块隔离，可以使用Mock对象来模拟协同模块预期的行为。这样做一是可以将本模块与其他依赖模块完全分隔开，这样检测不受协同模块开发进度的影响；另一方面通过与Mock对象协作，可以获得一个孤立的检测环境。此外，Mock对象还可以模拟在系统中不容易构造和比较复杂的对象，节省检测时间。

如图2所示，检测框架的具体实施方案有如下步骤：

(1)、在检测模块TestAuthorization里定义好检测的接口方法，检测接口定义如下：

Public void testGetAuthorizationById(String id)；

Authorization定义用户授权数据库；

String id定义查询数据库的索引值；

上面的testGetAuthorizationById接口用来检测业务模块对授权数据库Authorization的查询过程。

(2)、在检测模块里定义好检测组件用来对外提供统一的检测接口：

Public static Test suite(BundleContext bc)；

BundleContext bc是OSGi运行框架的容器环境；

Test返回检测用例的汇总，通过定义JunitTestSuite类型的suite变量，添加检测用例suite.addTestSuite(TestAuthorization.class)。

(3)、检测环境模块整体运行检测，TestRunner运行检测的接口定义如下：

Public void runAllTests(Map<String,Test>testcases)；

参数Map<String,Test>testcases用来收集所有从实例化Bean中获取的检测组件，其中String字段是检测组件的类名，Test字段是对应的以注解Test定义的Junit检测方法。

获取检测用例集合的接口定义如下：

Public Map<String,Test>getTestCases()；

其中实例化Bean通过继承自BeanFactory接口的ApplicationContext，使用其实现类ClassPathXmlApplicationContext，从类路径中寻找指定的XML配置文件，找到并装载完成ApplicationContext的实例化工作。

为了运行检测用例，需要在本模块里添加Junit运行环境。目的除了要为检测用例提供Junit检测框架的支持，还可以接受其他检测模块注册的检测用例，并且能够运行这些检测用例。

最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制，尽管参照上述实施例对本发明进行了详细的说明，所属领域的普通技术人员依然可以对本发明的具体实施方式进行修改或者等同替换，这些未脱离本发明精神和范围的任何修改或者等同替换，均在申请待批的本发明的权利要求保护范围之内。

Claims (9)

1.一种适用于OSGI的检测框架，其特征在于，所述框架包括业务模块、检测模块和检测运行环境模块。

2.根据权利要求1所述检测框架，其特征在于，编辑业务模块的元数据描述配置文件，将业务模块中需要进行检测的接口以osgi服务的方式对外导出。

3.根据权利要求1所述检测框架，其特征在于，将所述检测模块引入osgi服务，并在检测模块中编写检测用例。

4.根据权利要求3所述检测框架，其特征在于，所述检测用例确保方法接收预期范围内的输入，为每一次检测输入返回预期的输出。

5.根据权利要求1所述检测框架，其特征在于，每个检测模块中新建Junit检测组件，运行所述检测模块里所有的检测用例，每一个检测组件都声明一个Spring Bean。

6.根据权利要求5所述检测框架，其特征在于，在Spring配置文件里引入所述SpringBean，新建一个检测集合组件，实例化检测模块中的检测组件，遍历和执行所有的检测用例。

7.根据权利要求1所述检测框架，其特征在于，在写检测代码的过程中，若会出现检测业务模块方法依赖的业务模块没有完成的情况，为了不影响本业务模块的单元检测和能够和其他模块隔离，使用Mock对象来模拟协同模块预期的行为。

8.根据权利要求1所述检测框架，其特征在于，所述业务模块之间具有独立和依赖两种关系。

9.根据权利要求1所述检测框架，其特征在于，所述检测框架适用于OSGI环境与Maven持续集成环境结合在一起，进行持续集成检测。