0

你好骆驼社区，

我有一些关于测试执行和自动化的问题。我正在使用 Red Hat Fuse 7.7（即 Camel 2.21.0 和 Karaf 4.2.6 作为 OSGi 基础）。

我对自动化测试很感兴趣，因此实现了一些基于 CamelBlueprintTestSupport 的单元测试。但不幸的是，当有一堆测试（大约 20 个）时，测试执行的性能非常慢。其他人也有性能问题吗？是不是因为后台加载PojoSR的过程比较复杂？

我还尝试使用 Pax-Exam 设置集成测试。但是由于我的项目通常非常复杂，因此安装所有需要的功能和依赖组件需要很长时间。只有我在与框架作斗争吗？性能再次变差，似乎几乎不可能创建一个允许使用像 camel-sql 或 Drools (kie) 这样的依赖项的测试设置，因为它们再次依赖于 spring 等其他工件。

你有什么测试经验？您使用什么工具来检查您的集成是否为给定的输入生成正确的输出？

我期待听到您的经验并参与讨论。问候

4

1 回答 1

0

你所描述的，导致了测试金字塔。

编写大量非常快速的单元测试来测试你能想到的每一种特殊情况——方法或类级别。

但是在集成测试级别上，每个测试都需要一些时间来执行。因此，您应该将它们缩小到无法在较低测试级别进行测试的基本测试用例。

您将Camel Route 测试称为“单元测试”，但由于它们需要整个应用程序上下文或至少不仅仅是一个类，因此我会将它们算作金字塔中的更高级别（服务测试、组件测试，有很多周围的名字）。因此，我已经尝试将它们减少到所需的最低限度。

我降低骆驼测试工作量的策略很常见：

  • 我将 Java 代码放入 JavaBeans 并从路由中调用它们。像这样，我可以使用普通的 JUnit对 Java Bean 进行彻底的单元测试，而无需使用路由测试来测试所有这些变体。
  • 我分开我的路线。我没有创建具有数十个可能的代码执行路径的巨大路径，而是创建具有“1 到某些”可能执行路径的紧凑小路径。这与大方法与小方法的原理相同。可能路径的数量在巨大的方法或路线中成倍增加。
  • 我使用 Spring，而不是 OSGi，但 Spring Framework 的 Camel 测试类可以使用相同的 Spring 上下文运行所有测试方法（无需重新启动测试之间的上下文）。这显着减少了测试执行时间。但这取决于路由和测试要求（Spring可以在测试之间重新启动“脏上下文”是有原因的），而且我不知道蓝图测试的行为方式。
于 2020-12-04T16:50:31.947 回答