OSGi 单元测试，无需打包包的步骤答案

【问题标题】：OSGi unit testing without step that packages bundlesOSGi 单元测试，无需打包包的步骤
【发布时间】：2009-12-01 08:00:13
【问题描述】：

我检查了一些针对 OSGI 的测试解决方案，包括 PAX，并快速查看了 Spring DM 中的抽象 TestCase，但它们似乎都需要一个 jar 包和捆绑相关的包。我希望找到没有这个中间步骤的东西。

想象一下在类路径中打包包的能力，这样包 x 和 y 组成包 XY，包 x 和 z 组成包 XZ。 Bundle XZ 不会“看到”包“y”，但可以从包 x 中的 XY 导入服务。如果这是可能的或者是否存在等效的测试用例/库，是否有任何 cmets？

【问题讨论】：

一种观点可能是，单元测试 意味着从 OSGi 环境之外的单个包中测试类。如果您想测试来自多个捆绑包的服务之间的交互，它可能会更多地归类为集成测试。
@Pavel 是我的错误，q 应该读为 integ 而不是单元测试，或者可能只是简单的“测试”。

【解决方案1】：

我认为将 OPS4J 中的 Tiny Bundles 与 Pax Exam 结合使用正是您想要的。

【讨论】：

Pax Exam 和 Tiny Bundles 似乎仍然非常专注于以某种形式创建捆绑包（即使它在内存中）。我需要更好地看一下，但它们似乎直到需要从某些类路径（如源）中提供类文件，这与常规测试不同。许多博客似乎表明，运行 pax 考试测试非常缓慢，而且不像常规 junit 测试用例所期望的那样即时。
@Alin 我相信您来自 PAX :) 对于库来说，我是否还建议您一次下载所需的一切，而不是要求用户一个一个地抓取。

【解决方案2】：

如果您真的想强制执行运行时可见性规则，那么您可能必须在 OSGi 环境中运行测试并支付一些性能开销。

但是，通过将类分成具有适当依赖关系的不同编译单元（例如，单独的 Maven 模块 X、Y、Z），然后在没有 OSGi 的情况下运行标准测试框架（例如 JUnit），对您来说可能就足以强制编译时可见性.

【讨论】：