testing - 如何测试作为 OSGi Bundle 实现的服务契约？

Question

我们正在向 SOA 过渡。

我们当前的目标是尝试并确保将更多应用程序开发为“服务”(主要是为了提高功能的可见性、重用和降低变更风险)。其中一些服务将作为 Web 服务公开，但许多(可能是大多数)不会公开，并且仅供“内部”使用以帮助获得 SOA 的一些好处。

对于那些“内部”服务，我们目前打算将它们实现为 OSGi 包；然而，我们正在努力了解如何最好地测试它们。我们的目标是让当前的系统测试团队能够测试所有类型的服务，并且我们一直在研究 SoapUI 和 SOA Test 等工具；然而，越来越清楚的是，在使用这些工具测试我们作为 OSGi bundle 实现的服务时，我们可能会面临一些挑战；并且确实要求测试团队这样做。

因此，我们正在寻找一些建议，以了解如何最好地测试我们旨在充当“服务”但作为 OSGi 包而不是 Web 服务实现的能力的各个方面。

人们会推荐什么工具，这是一种传统上由开发人员在单元测试期间完成的测试类型，还是可以由技术水平较低的测试人员完成，采用相同的测试接口(interface)基本原则(即输入、处理) , 输出)?

Answer 1

理论上，您可以使用远程服务管理实现(如 Aries RSA 或 Eclipse ECF)在测试期间向外部公开您的内部服务，以便使用外部系统测试工具访问它们。

不过，我不建议让外部团队测试您的 OSGi 服务。最好使用像 pax exam 这样的集成测试工具在您自己的构建中测试服务。 .它允许定义要安装的包和其他配置。然后它会根据您的设置启动一个 OSGi 框架，并针对它运行修改后的 junit 测试。优点是这样的测试非常现实并且仍然非常简单。请在此处查看 aries rsa 中的一些 pax 考试测试或 apache karaf .第一个示例使用 pax exam fork 容器进行非常快速的测试(每次测试 <1 秒)，而第二个示例使用 apache karaf 容器(每次测试约 10 秒)进行非常接近生产系统的测试。

与外部系统测试团队相比，您可以获得更快的反馈，而外部系统测试团队总是会落后于您当前的开发。它还允许您建立每个团队成员在提交之前在本地运行测试的策略。