Java OSGi组件的单元测试

我目前正在考虑“如何设计OSGi组件，以便使用jUnit和Mockito等框架为其编写测试”

模拟捆绑包之间的依赖关系非常容易，因为OSGi加强了DIP（依赖关系倒置原则）和通常存在的注入方法（如setter）。
但是bundle内部依赖性呢

例如，看看。现在我想把它放到OSGi上下文中。。。我们希望在OSGi平台中提供任何类型的网络协议作为声明性服务，并希望编写单元测试来测试与套接字对象直接交互的底层网络代码

如果我们要将套接字创建重构为一个单独但仍然捆绑的内部POJO（普通旧Java对象）类，我们应该如何将其注入协议实现中

• 在单元测试中，我们可以简单地使用setter方法，但是谁会在OSGi容器中为我们这样做呢
• 只有在测试类未声明为final时，子类化测试类并覆盖creator方法才会起作用

  ---

严格来说，测试与OSGi容器的交互是一种集成测试。对于这一点，您可以使用它，它有点难以掌握，但效果非常好（特别是如果您使用的是maven和/或karaf特性）

此外，您可以使用它从测试中动态创建可部署的捆绑包/片段（非常酷），模拟其他捆绑包/片段，以确保捆绑包之间的集成，而无需构建完整的环境

对于单元或小规模集成测试（即没有容器），如果需要，您可以模拟BundleContext（或者如果使用DS组件上下文）

我不太清楚你在要点中的问题。如果存在内部POJO，则您有责任通过setter连接依赖关系，否则，如果它暴露于OSGi服务注册表，则依赖关系由框架（DS或ServiceTracker）解决

---

另外，子类化某些内容以覆盖creator方法意味着您不再测试原始类-这是一种代码气味-尝试将其重构以作为单独的类（构造函数或setter）传入creator代码，然后可以独立测试此新的creator代码（套接字创建）（不考虑OSGi，甚至不考虑使用它的协议类）.

如果我在OSGi容器中运行的OSGi组件中使用POJO，组件本身必须在构造函数代码中创建POJO实例，因为容器无法注入它。我应该如何在单元测试中拦截此过程？当然，我可以创建一个setter方法来覆盖先前创建的POJO在组件内部，但这也有一些代码味道。“我们真的像在容器中运行一样测试组件的代码吗？”一些副作用，如在构造函数代码中调用POJO，可能会发生并破坏我的测试。我想我明白了，您有一个POJO在其构造函数中创建其他POJO（或作为初始化字段），例如，创建套接字的协议类？如果是这种情况，则需要将套接字的创建与协议类分开-作为构造函数arg传递或使用setter应用（但从协议类中删除任何套接字创建）通过这种方式，您可以传入模拟套接字进行单元测试，而对于您的捆绑包，您可以创建一个SocketServiceFactory，返回真实的套接字（生产）对于容器测试，模拟此服务以返回模拟SocketsPerfect。使用透明的ServiceFactory当然是我想要的。以前我认为ServiceFactory和ComponentFactory是一样的。；）酷，好运&快乐编码=）（你介意投票回答吗，谢谢）好的，我还有一个问题。；）我目前正在使用BundleContext.registerService注册服务工厂。是否有可能让框架在我自己的工厂创建的实例中注入其他服务？