我目前正在考虑“如何设计 OSGi 组件，以便使用 jUnit 和 Mockito 等框架轻松为其编写测试”.
由于 OSGi 增强了 DIP，因此模拟捆绑包间的依赖关系非常容易（依赖倒置原理）和注入器方法（例如 setter）通常存在。
但是捆绑包的内部依赖关系又如何呢？
例如看看这个案例 https://stackoverflow.com/questions/5577274/testing-java-sockets。现在我想将它带入 OSGi 上下文中...图像我们希望在 OSGi 平台中提供任何类型的网络协议作为声明性服务，并希望编写单元测试来测试直接与底层网络交互的网络代码套接字对象。
如果我们将套接字创建重构为一个单独但仍然捆绑的内部 POJO（普通的旧 Java 对象）类，我们应该如何将它注入到协议实现中？
- 在单元测试中，我们可以简单地使用 setter 方法，但谁会在 OSGi 容器中为我们执行此操作？
- 仅当测试类未声明为最终类时，对测试类进行子类化并覆盖创建者方法才有效。
严格来说，测试与 OSGi 容器的交互是集成测试。为此你可以使用Pax Exam http://team.ops4j.org/wiki/display/ops4j/Pax+Eclipse+Plugin，掌握窍门有点麻烦，但效果很好（特别是如果您使用 Maven 和/或 karaf 功能）。
另外你可以使用小捆绑包 http://team.ops4j.org/wiki/display/ops4j/Tinybundles它可以从测试中动态创建可部署的捆绑包/片段（非常酷），以模拟其他捆绑包/片段，以确保捆绑包间集成，而无需启动完整的环境。
对于单元或小规模集成测试（即没有容器），如果需要，您可以模拟 BundleContext（或者如果使用 DS，也可以模拟 ComponentContext）。
我对要点中的问题有点不清楚。如果有内部 POJO，那么您有责任通过 setter 连接依赖项，否则，如果它暴露给 OSGi 服务注册表，则依赖项将由框架（DS 或 ServiceTracker）解析。
另外，子类化某些东西来覆盖创建者方法意味着您不再测试原始类 - 这是一种代码味道 - 尝试重构它以将创建者代码作为单独的类（构造函数或设置器）传递，然后是这个新的创建者代码（套接字创建）可以独立测试（不考虑 OSGi，甚至不考虑将使用它的协议类）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
