OSGi单元测试和包导出

Question

mybundle
  src/java
    mybundle.package1
      ...java
  bnd.bnd

mybundle
  src/java
    mybundle.package1
      ...java
  test/java
    mybundle.package1.test
      ...java
  bnd.bnd

注意附加的'.test'以区分包并避免拆分包问题。

通常，会有一些措施来确保测试类不会最终出现在构建的bundle jar中。

这里添加了一个单独的bundle，name后缀“.test”，这是常规做法。

mybundle
  src/java
    mybundle.package1
      ...java
mybundle.test
  test/java
    mybundle.package1.test
      ...java
  bnd.bnd

mybundle.fragment
  test/java
    mybundle.package1.test
      ...java
  bnd.bnd

这对于第二种选择最为明显，即拥有单独的测试包。测试包中的测试必须导入-打包待测类，而待测包也必须导出-打包所有所述待测类。

因此，显而易见的解决方案是倾向于在bundle源代码中进行单元测试，但问题很快就会出现在非常重要的情况下。您可能希望共享测试代码，例如，您可能将OSGi集成测试放在一个单独的包中。为了共享代码，您最终不得不导出打包测试包，然后当然您也最终在构建的包中使用测试代码！

组织OSGi包/项目进行测试的最佳方式是什么？

Answer 1

第三种选择是使用OSGi片段进行单元测试。这确保了测试与要测试的代码共享一个类加载器，因此不需要额外的内部包的包导出。如果需要，测试片段甚至可以导出主包的内部包。该片段将有自己的包导入，因此它可以拉入共享测试代码，而不会污染主包的包导入。

正如上面的注释和更新的原始问题中提到的，使用片段仍然会给您留下一些关于如何处理构建和类路径的问题。如果您是在OSGi容器外运行测试，那么片断的类加载器优势基本上就会消失，可能除了在IDE中引入导入的测试依赖项之外。

如果您是在OSGihtml" target="_blank">容器中运行测试，那么与普通包相比，碎片确实有一些缺点，这可能是一个问题，这取决于您是如何驱动测试的。片段不能声明激活器，因为它们没有独立的生命周期。声明性服务也不能以自然的方式从片段注册，尽管蓝图服务通常可以。