ESB 应用程序和持续集成

Question

我已经将 Junit 和 CI 用于纯粹基于 Java 的应用程序，效果很好。 Junit 用于通过传递其输入值（参数）来对 operation/method 的用例进行单元测试，并期望 return 值应符合条件。通常我们会针对具有控制器、服务和 DAO 层的纯 java 应用程序测试 junit。有时将模拟对象用于 mock/proxy 第三方应用程序。

现在，我在 Mule 上构建了 ESB 应用程序，它有 http 连接器，api 带有 raml 的套件，调度程序，云连接到 sfdc，ActiveMQ，smtp，JDBC 连接到多个数据库, datampaper, datewave 并继续..

最后，Mule 应用程序是一个 xml 文件，其中集成了 Java/Groovy 和一些其他技术。 Java 组件仅占应用程序构建组件的 10%（或有时 none）。

我正计划与 Jenkins 进行持续集成。为此，我需要运行 Junit 框架来对应用程序进行回归测试。我希望 Munit 不能与 CI 一起使用，因为 Munit 必须与 Studio 一起执行，并且它是在 xml 文件中编写的。

由于构建的应用程序不完整 Java 基于应用程序（我们可以在其中编写单元测试断言操作及其 returning 值）观察到的问题：

为 Mule 组件编写 Junit 比编写功能要花很多时间，因为获取 Mule xml 组件和模拟组件的代码长度更长。
我无法为 Mule ESB 应用程序实现 100% 的代码覆盖率。我可以在基于 Java/Junit 的应用程序中使用 cobertura 或其他工具进行代码覆盖。
开发人员可以利用时间进行手动测试来获得更稳定的应用程序，而不是花时间在此单元测试上。

此外，构建 ESB 应用程序是为了将运行不同的流程集成在一起。对于基于 ESB 的应用程序，将 CI 与 Junit 一起使用是否是好的架构建议？或者在没有 CI 和 Junit 测试的情况下在服务器中构建、执行手动测试和部署应用程序？

Answer 1

Mule ESB 完全基于Java/Spring。如果您将项目设置为具有适当依赖项的 Maven 项目，那么您可以运行在 Studio 之外进行 munit 测试。

实际上在高级培训课程中已经涵盖了。 https://training.mulesoft.com/instructor-led-training/advanced-development-online-37

Answer 2

您似乎对为 Mule ESB 应用程序实施持续集成提出了许多担忧。我将尝试在下面陈述并回答您的每一个问题。如果我有什么不明白的地方，请更新问题，我会相应地修改答案。

Is my CI process limited to junit based tests alone, or can I also use MUnit tests?

如果您使用 maven 来自动化您的构建，您可以在您的 CI 过程中包括基于 MUnit 的测试和基于 junit 的测试。要运行 MUnit 测试，请将以下插件添加到您的 POM：

<plugin>
  <groupId>com.mulesoft.munit.tools</groupId>
  <artifactId>munit-maven-plugin</artifactId>
  <version>1.0.0</version>
  <executions>
    <execution>
      <id>test</id>
      <phase>test</phase>
      <goals>
        <goal>test</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Should I expect to spend more time and effort writing tests for a Mule application than I do for a pure java application?

我将回答我推荐为 Mule 应用程序编写的两类测试。

功能测试
- 格式： JUnit with FunctionalTestCase
- 学习曲线： 个月
- 初学者所需时间：比纯java
- 经验所需时间：与纯java
单元测试
- 格式：MUnit
- 学习曲线： 天
- 初学者所需时间：比纯java
- 经验所需时间：与纯java

首先，我认为最重要的是功能测试。这些应该是粗粒度的、黑盒的和隔离的。这些是用 JUnit 编写的，并且基于 Mule TCK and the FunctionalTestCase 基础 class。熟练开发这些测试似乎需要一段时间，并且需要在几个不同的应用程序上进行体验。一旦你掌握了它，并建立了一组你喜欢的支持 java 库，我希望这些库花费的时间与 "pure java".

中的等价物一样长。

单元测试主要使用 MUnit 编写，并使用特定的输入消息测试流程或子流程。这些似乎与使用 junit for "pure java" 占用的开发时间比例大致相同。学习曲线也相当快：对于使用 TDD 且对 Mule 开发有相当了解的 java 开发人员，我希望能花几天时间。

Is there any way to measure code coverage of my Mule application's test suite?

我还没有看到任何方法来衡量您的 CI 过程中的覆盖率。但是，Anypoint Studio can measure coverage 在开发时。

Given the time required to write automated tests, and the lack of design time reuse, would it be smarter to spend time manually testing instead of creating an automated test suite and implementing a CI process?

没有。我已经在许多 Mule 开发项目和六个团队中实施了自动化测试的持续集成，但并不是所有团队都以 100% 的热情采用。 :) 您在前几个项目中花费的额外开发时间很快就会被遗忘，而收益将在软件的整个生命周期内保持不变。

ESB 应用程序和持续集成

ESB applications and Continuous Integration

architecture

continuous-integration

mule