一种适用于OSGI的检测框架制造技术

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

【技术实现步骤摘要】
【专利摘要】本专利技术提供了一种适用于OSGI的检测框架，该框架在OSGI环境中运行基本的Junit单元检测，建立单独的检测模块，把业务逻辑代码和检测代码完全分离，为后续项目构建和集成提供前提便利条件，检测运行环境收集所有检测模块里的检测用例，以集合的形式，对所有的检测用例进行汇总，方便检测的整体运行。【专利说明】—种适用于OSGI的检测框架
本专利技术涉及一种软件构件化设备，具体涉及一种适用于OSGI的检测框架。
技术介绍
OSGI (Open Service Gateway Initiative)技术是面向 Java 的动态模型系统，OSGi的主要职责是让开发者能够构建动态化、模块化的Java系统。使用OSGi后，应用的过程就像搭积木一样搭建，例如，对于一个正在运行的系统，其中一个模块要使用日志服务，但是目前的系统并没有提供日志服务的模块，此时可以直接从网上下载实现日志服务API的模块，然后动态安装此模块，随后其他要使用日志服务的模块就可以使用了。 在OSGi环境里，针对业务逻辑模块，编写专门的检测模块，这样可以做到检测代码和业务逻辑代码完全分离。提供包含Junit检测框架的检测环境模块收集各个检测模块的检测用例，并且为检测模块提供Junit运行环境支持。 OSGi框架中每一个模块都是一个Bundle，Bundle从形式上讲是在META-1NF目录下的MANIFEST.MF文件中加入了 OSGi特定描述的一个jar包。Bundle的生命周期被OSGi 框架管理。 目前业界广泛应用的OSGi运行框架，被称为Java语言的动态模块系统。它为模块化应用的开发定义了一个基础架构，它使用Bundle的概念把复杂的应用程序模块化。Bundle的生命周期由OSGi运行框架维护，并且Bundle之间是相互依赖的,这也决定了加载Bundle时的顺序。在带来松耦合互相依赖的同时，也产生了严格的访问控制，只有少数的接口能够被其他Bundle访问到，传统的单元检测无法在OSGi环境里运行。在检测中，经常需要对Bundle中非公开的包或方法进行检测。并且检测代码如何与业务逻辑代码分开也存在问题。 OSGi运行环境经常是由十几个或者几十个Bundle组成，如果针对每一个Bundle都写好检测代码，那么单独运行每一个检测用例也很麻烦，需要手动去执行每一个TestCase0如何把所有的检测用户汇总在一个专门的检测Bundle里面,能够一次性运行所有的检测，也是面临的一个问题。 所以需要针对OSGi特点，提供一种单元检测框架，该框架可以在OSGi环境中运行基本的Junit单元检测，把业务逻辑代码和检测代码完全分离，并且通过专门的检测运行环境对所有的检测用例进行汇总，方便检测的整体运行。
技术实现思路
为了克服上述现有技术的不足，本专利技术提供一种适用于OSGI的检测框架，该框架可以在OSGI环境中运行基本的Junit单元检测。建立单独的检测模块，把业务逻辑代码和检测代码完全分离，为后续项目构建和集成提供前提便利条件。检测运行环境收集所有检测模块里的检测用例，以集合的形式，对所有的检测用例进行汇总，方便检测的整体运行。 为了实现上述专利技术目的，本专利技术采取如下技术方案: 一种适用于OSGI的检测框架，其包括多个业务模块、多个检测模块和检测运行环境模块。 本专利技术提供的优选技术方案中，编写业务模块的元数据描述配置文件，将业务模块中需要进行检测的接口以OSgi服务的方式对外导出。 本专利技术提供的第二优选技术方案中，所述检测模块分别引入OSgi服务，并编写检测用例。 本专利技术提供的第三优选技术方案中，所述检测用例确保方法接收预期范围内的输入，为每一次检测输入返回预期的输出。 本专利技术提供的第四优选技术方案中，每个检测模块中，都新建Junit检测组件，运行所述检测模块里所有的检测用例，每一个检测组件都声明一个Spring Bean。 本专利技术提供的第五优选技术方案中，在Spring配置文件里引入所述SpringBean，新建一个检测集合组件，实例化检测模块中的检测组件，遍历和执行所有的检测用例。 本专利技术提供的第六优选技术方案中，在写检测代码的过程中，若会出现检测业务模块方法依赖的业务模块没有完成的情况，为了不影响本业务模块的单元检测和能够和其他模块隔离，使用Mock对象来模拟协同模块预期的行为。 本专利技术提供的第七优选技术方案中，所述多个业务模块之间具有独立和依赖两种关系。 本专利技术提供的第八优选技术方案中，所述检测框架适用于OSGI环境与Maven持续集成环境结合在一起，进行持续集成检测。 与最接近的现有技术比，本专利技术的有益效果: 本专利技术提供的技术方案使用EasyMock来模拟其他模块的功能，在明确的知道其他模块接受的指令和返回的结果的情况下，通过这个方式可以实现对模块之间逻辑调用的检测。由于这种方法并没有实际调用其他模块，所以待依赖模块开发完成之后，可以使用加载依赖Bean的方式对依赖的模块功能进行调用，实现模块的单元检测部分。 本专利技术提供的框架中结合Mock模拟的思想，可以将本模块与其他依赖模块完全分隔开，这样检测不受协同模块开发进度的影响；另一方面通过与Mock对象协作，可以获得一个孤立的检测环境。 【专利附图】【附图说明】 图1是框架的整体架构设计图 图2是检测方案的功能分布图 【具体实施方式】 下面结合附图对本专利技术作进一步详细说明。 假设现在运行环境里包含两个业务模块:A和B，且A、B之间有依赖关系。检测框架的具体设计如下: (I)、编辑两个业务模块的元数据描述配置文件，将两个模块中需要进行检测的接口以osgi服务的方式对外导出。 通过注册osgi服务，检测模块可以在OSGi容器里引用这些服务用来进行单元检测。 (2)、新建检测模块=TestA和TestB，分别引入上一步中的osgi服务，编写检测用例。 检测用例确保方法接受预期范围内的输入，并且为每一次检测输入返回预期的输出。 (3)、在检测模块里，新建Junit检测组件(Test Suite)，涵盖检测模块里所有的检测用例。 通过这样的方式，为每一个模块内的检测用例提供一个整体对外接口，这样可以通过调用这个接口一次性运行所有的检测用例。每一个检测组件都声明成一个SpringBean0 (4)、新建检测环境模块,在Spring配置文件里引入Spring Bean。新建一个检测集合组件(Test Runner)，通过实例化其他检测模块的检测组件Bean，可以遍历和执行所有的检测用例。 这里需要在OSGi环境里集成Spring环境，这样才能正常定义和实例化Bean。在实例化Bean的过程中，可以使用Applicat1nContext通过ClassPathXmlApplicat1nContext读取依赖的xml文件来实现。对于实例化过程中一些可以忽略的空指针问题，可以使用Mock来模拟预期行为。 通过类的名字和包名注册Bean并发布为OSGi服务。在写检测代码的过程中，可能会出现检测方法依赖的模块还没有完成的情况，此时为了不影响本模块的单元检测，也为了能够将本模块与其他模块隔离，可以使用Mock对象来本文档来自技高网...

【技术保护点】
一种适用于OSGI的检测框架，其特征在于，所述框架包括业务模块、检测模块和检测运行环境模块。

【技术特征摘要】

【专利技术属性】
技术研发人员：郝秋影，郭鹏，李守超，
申请(专利权)人：曙光信息产业北京有限公司，
类型：发明
国别省市：北京;11