Mulesoft 简明教程

Mule项目始于2003年4月的SourceForge项目，两年后其第一版发布并转移到CodeHaus。通用消息对象（UMO）API是其架构的核心。UMO API背后的理念是统一逻辑，同时使它们与底层传输保持隔离。

它于2005年4月发布，其中包含许多传输。随后许多其他版本的主要重点是调试和添加新功能。

Spring 2作为配置和连接框架被采纳到Mule 2中，但它被证明是一次重大的检修，因为缺少对必需的XML配置的表达力。当基于XML架构的配置被引入Spring 2时，此问题得到解决。

在开发和部署时简化Mule使用的最大改进是使用Maven。从1.3版本开始，它开始使用Maven构建。

2006年，MuleSource成立，旨在“帮助支持和支持在关键任务企业应用程序中使用Mule的快速增长社区”。这被证明是Mule项目的关键里程碑。

此项任务涉及开发或重复使用现有的POJO或Spring Bean。POJO是一个带有属性的类，该属性生成get和set方法、云连接器。另一方面，Spring Bean包含用于丰富消息的业务逻辑。

此项任务基本提供了涉及配置消息处理器、路由器、转换器和过滤器的服务中介。

Mule ESB的最重要任务是集成各种应用程序，无论它们使用的协议如何。为此，Mule提供了传输方法，允许在各种协议连接器上接收和分发消息。Mule支持许多现有的传输方法，或者我们还可以使用自定义传输方法。

Spring bean 的主要用途是构建服务组件。构建 Spring 服务组件后，如果用户没有配置文件，可以通过配置文件或手动定义服务组件。

它最初是 Anypoint Studio 中在 Mule Studio 之前创建的服务。一旦服务器启动，将会创建一个代理，一旦服务器停止，将会销毁该代理。

它是一个软件组件，配置为特定于协议的参数。它主要用于控制协议的使用。例如，JMS 连接器配置有 Connection ，该连接器共享在负责实际通信的不同实体之间。

顾名思义，这个构建块用于设置全局属性和设置。

它可以在“全局元素”选项卡中使用，该选项卡可以在流程中多次使用：

顾名思义，它观察或修改消息或消息流。转换器和过滤器是全局消息处理程序的示例。

Transformers - 转换器的主要工作是将数据从一种格式转换成另一种格式。可以在全局中定义，并可以在多个流程中使用。

Filters - 它是一个过滤器，将决定应该处理哪条 Mule 消息。过滤器基本上指定消息必须满足的条件，然后才能处理并路由到服务。

与代理相反，它是工作室中创建的服务的逻辑分组。我们有权启动和停止特定模型中的所有服务。

Services - 服务是封装业务逻辑或组件的服务。它还专门为该服务配置了路由器、端点、转换器和过滤器。

Endpoints - 可以将其定义为一个对象，服务将在其上入站（接收）和出站（发送）消息。服务通过端点连接。

消息处理器使用流程在源与目标之间定义消息流。

它只不过是消息的元数据，由以下两个属性进一步表示：

Inbound Properties - 这些属性由消息源自动设置。它们不能由用户操作或设置。本质上，入站属性是不可变的。

Outbound Properties - 这些属性是包含元数据的属性，比如入站属性，可以在流程期间设置。它们可以由 Mule 自动设置，也可以由用户手动设置。本质上，出站属性是可变的。

当消息通过一个流程的出站端点通过传输转到另一个流程的入站端点时，出站属性将变为入站属性。

当消息通过 flow-ref 而不是连接器转到新流程时，出站属性仍保持出站属性。

消息对象承载的实际业务消息称为有效负载。

它可以定义为关于消息的用户自定义元数据。基本上，变量是有关于由正在处理该消息的应用程序使用的消息的暂时信息片段。它不应该与消息一起传递到其目的地。它们有以下三种类型 −

Flow variables − 这些变量仅适用于它们存在的流。

Session variables − 这些变量适用于同一应用程序中的所有流。

Record variables − 这些变量仅适用于作为一个批处理的一部分处理的记录。

这些是关于消息有效负载的一些额外的元数据，它不一定每次都出现在消息对象中。

在安装 MULE 之前，请验证您的系统上是否支持 Java 版本。建议使用 JDK 1.8.0 在您的系统上成功安装 Mule。

Mule 支持以下操作系统−

由于 Mule Runtime 以独立服务器的形式运行，因此不需要应用程序服务器或数据库。但是，如果我们需要访问数据存储或想要使用应用程序服务器，可以使用以下受支持的应用程序服务器或数据库−

现在，要测试 Mule 是否在您的系统中无任何错误地运行，请使用以下命令−

以上命令将在前台模式下运行 Mule。如果 Mule 正在运行，我们无法在终端上发布任何其他命令。在终端中按 ctrl-c 命令将停止 Mule。

若要作为 Windows 服务运行 Mule，我们需要按照如下步骤 −

Step 1 - 首先，借助以下命令安装它 −

Step 2 - 安装完成后，借助以下命令，我们可以将 mule 作为 Windows 服务运行：

若要将 Mule 作为 Linux/Unix 守护进程运行，我们需要按照以下步骤操作：

Step 1 - 在安装它的帮助下使用以下命令进行安装：

Step 2 - 安装后，我们可以在以下命令的帮助下将 mule 作为 Windows 服务运行：

Example

以下示例将 Mule 作为 Unix 守护进程启动：

要在 Windows 上下载并安装 Anypoint Studio，我们需要执行以下步骤 −

Step 1 − 首先，单击链接 https://www.mulesoft.com/lp/dl/studio 并从下拉列表中选择 Windows 操作系统下载该工作室。

Step 2 − 现在，将其提取到 ‘C:\’ 根文件夹。

Step 3 − 打开提取的 Anypoint Studio。

Step 4 − 要接受默认工作区，请单击确定。首次加载时，您将收到欢迎消息。

Step 5 − 现在，单击入门按钮以使用 Anypoint Studio。

要在 OS X 上下载并安装 Anypoint Studio，我们需要执行以下步骤 −

Step 1 − 首先，单击链接 https://www.mulesoft.com/lp/dl/studio 并下载该工作室。

Step 2 − 现在，将其提取。如果你正在使用 OS 版本 Sierra，请务必在启动之前将提取的 App 移至 /Applications folder 。

Step 3 − 打开提取的 Anypoint Studio。

Step 4 − 要接受默认工作区，请单击确定。首次加载时，您将收到欢迎消息。

Step 5 − 现在，单击 Get Started 按钮以使用 Anypoint Studio。

如果你打算对工作区使用自定义路径，请注意 Anypoint Studio 不会展开 Linux/Unix 系统中使用的波浪号 (~)。因此，建议在定义工作区时使用绝对路径。

要在 Linux 上下载并安装 Anypoint Studio，我们需要执行以下步骤 −

Step 1 − 首先，单击链接 https://www.mulesoft.com/lp/dl/studio 并从下拉列表中选择 Linux 操作系统下载该工作室。

Step 2 − 现在，将其提取。

Step 3 − 接下来，打开提取的 Anypoint Studio。

Step 4 − 要接受默认工作区，请单击确定。首次加载时，您将收到欢迎消息。

Step 5 − 现在，单击入门按钮以使用 Anypoint Studio。

如果你打算对工作区使用自定义路径，请注意 Anypoint Studio 不会展开 Linux/Unix 系统中使用的波浪号 (~)。因此，建议在定义工作区时使用绝对路径。

还建议安装 GTK 版本 2 来在 Linux 中使用完整的工作室主题。

Package Explorer 视图的主要任务是显示 Mule 项目中包含的项目文件夹和文件。我们可以通过单击它旁边的箭头来展开或收缩 Mule 项目文件夹。可以通过双击打开文件夹或文件。看看它的截图 −

Mule Palette 视图显示了事件处理器，如范围、过滤器和流控制路由器，以及模块及其相关操作。Mule Palette 视图的主要任务如下 −

看看它的截图 −

顾名思义，它允许我们编辑画布中当前所选模块的属性。Mule 属性视图包括以下内容：

以下是屏幕截图：

每当我们创建或运行 Mule 应用程序时，嵌入式 Mule 服务器都会显示一个事件列表和问题列表（如果有的），由 Studio 报告。控制台视图包含该嵌入式 Mule 服务器的控制台。看看其屏幕截图：

我们在处理 Mule 项目时可能会遇到许多问题。所有这些问题都显示在“问题”视图中。以下是屏幕截图

在 Anypoint Studio 中，它是一个按指定方式排列的视图和编辑器的集合。Anypoint Studio 中有两种透视图：

Mule Design Perspective - 这是我们在 Studio 中获得的默认透视图。

Mule Debug Perspective - Anypoint Studio 提供的另一个透视图是 Mule 调试透视图。

另一方面，我们还可以创建自己的透视图，并可以添加或删除任何默认视图。

创建 Mule 应用程序的第一步是创建一个新项目。它可以通过按照 FILE → NEW → Mule Project 中所示的路径完成，如下所示−

按照上述说明，在单击“新建 Mule 项目”之后，将打开一个新窗口，询问项目名称和其他规范。输入项目名称“ TestAPP1 ”，然后单击完成按钮。

单击完成按钮后，将打开为 MuleProject 建立的工作区，即 ‘TestAPP1’ 。您可以看到前一章中描述的所有 Editors 和 Views 。

在此，我们将为 HTTP Listener 构建一个简单的 Mule 应用程序。为此，我们需要从 Mule Palette 拖动 HTTP Listener 连接器并将其放到工作区，如下所示 −

现在，我们需要配置它。如上所示，在基本设置下，单击连接器配置之后的绿色 + 号。

单击确定后，将转到 HTTP Listener 属性页面。现在我们需要在常规选项卡下提供路径。在此特定示例中，我们已 /FirstAPP 提供为路径名称。

现在，我们需要使用 Set Payload 连接器。我们还需要在设置选项卡下提供其值，如下所示 −

This is my first Mule Application ，是本示例中提供的名称。

现在，将其保存并单击 Run as Mule Application ，如下所示 −

我们可以在控制台中进行检查，以下是其部署应用程序的方式 −

它显示您已成功构建您的第一个 Mule 应用程序。

以下是将两个字符串连接成一个字符串的简单示例：

上述 DataWeave 脚本带有键值对 ({ myString: ("hello" ++ "World") }) ，它会将两个字符串连接成一个字符串。

以下是基于功能划分的 Mule 处理器类别： −

以下是为 Mule 应用程序中的流程添加关键绩效指标的步骤：

Step 1 - 按照 Mule Palette → Core → Components → Custom Business Event 添加 Custom Business Event 组件到 Mule 应用程序中的工作流中。

Step 2 - 单击组件以将其打开。

Step 3 - 现在，我们需要为显示名称和事件名称提供值。

Step 4 - 要从消息有效负载中捕获信息，请添加关键绩效指标，如下所示：

以下表格由名称和价值的 KPI 列表组成 −

以下是一个通过 ID 查询参数从数据库中选择脚本并将其存储在名为 MyScript 的变量中的示例。现在，动态评估组件将访问变量以调用脚本，以便它可以从 UName 查询参数中添加一个 name 变量。

流程的 XML 配置如下所示 −

脚本可以使用消息、负载、变量或属性之类的上下文变量。但是，如果你想要添加自定义上下文变量，你需要提供一组键值对。

以下表格提供了配置 Dynamic Evaluate 组件的方法 −

以下是此核心组件的特征 −

通过以下图表可以了解流引用组件的工作原理 −

该图表显示当一个流引用同一个应用程序中的另一个流时，Mule 应用程序中的处理顺序。当 Mule 应用程序中的主工作流被触发时，Mule 事件会一直传递并执行流，直到 Mule 事件到达流引用。

在到达流引用后，Mule 事件从头到尾执行引用流。一旦 Mule 事件完成执行引用流，它将返回到主流。

为了更好地理解， let us use this component in Anypoint Studio 。在此示例中，我们将 HTTP 侦听器用于 GET 消息，正如我们在上一章节中所做的一样。因此，我们可以拖放组件并进行配置。但对于此示例，我们需要添加子流组件并在其下方设置有效负载组件，如下所示 −

接下来，我们需要通过双击配置 Set Payload 。此处我们给出的值“子流已执行”，如下所示 −

在成功配置子流组件后，我们需要将流引用组件设置在主流中设置有效负载之后，该组件可从 Mule Palette 中拖放，如下所示 −

接下来，在配置流引用组件时，我们需要在通用选项卡下选择流名称，如下所示 −

现在，保存并运行此应用程序。要对此进行测试，请转至 POSTMAN，在 URL 栏中键入 http:/localhost:8181/FirstAPP ，然后您将收到消息“子流已执行”。

以下是记录器组件的一些优点：

以下示例在浏览器中 Set Payload 中显示消息“Hello World”，并同时记录消息。

以下是上述示例中的流的 XML 配置 −

我们可以借助以下两个方法构建转换 −

Drag-and-Drop Editor (Graphical View) − 这是构建转换的第一种且是最常用的方法。在此方法中，我们可以使用此组件的可视化映射器来拖放传入数据结构的元素。例如，在以下示意图中，两个树视图显示了输入和输出的预期元数据结构。连接输入到输出字段的线表示两个树视图之间的映射。

Script View − 转换的可视化映射也可在 DataWeave（用于 Mule 代码的语言）的帮助下表示。我们可以对高级转换（例如聚合、规范化、分组、连接、分区、旋转和筛选）进行编码。示例如下 −

此核心组件主要接受变量、属性或消息有效负载的输入和输出元数据。我们可以为以下内容提供特定于格式的资源 −

在使用调度程序事件时，我们需要考虑以下一些重要事项：

以下是要在常规时间间隔触发流的调度程序的参数：

Frequency - 它基本上描述了调度程序端点将触发 Mule 流的频率。可以从时间单位字段中为其选择时间单位。如果您不为此提供任何值，它将使用 1000 的默认值。另一方面，如果您提供 0 或负值，它也将使用默认值。

Start Delay - 这是应用程序启动后第一次触发 Mule 流之前我们必须等待的时间量。启动延迟的值以与频率相同的时间单位表示。它的默认值为 0。

Time Unit - 它描述了频率和启动延迟的时间单位。时间单位的可能值是毫秒、秒、分钟、小时、天。默认值为毫秒。

实际上，Cron 是用于描述时间和日期信息的标准。如果您使用灵活的 Cron 表达式来使调度触发器触发，则调度程序端点将跟踪每秒，并在 Quartz Cron 表达式与时间日期设置相匹配时创建一个 Mule 事件。使用 Cron 表达式，可以一次触发事件或在常规时间间隔触发。

下表给出了六个必填设置的日期时间表达式：

以下是一些由调度程序端点支持的 Quartz Cron 表达式的示例：

以下代码每秒钟记录一次消息“hi”−

使用选择路由器的效果就像向流程或大多数编程语言中的 if/then/else 代码块添加条件处理。以下是包含三个选项的选择路由器的原理图。其中，一个是默认路由器。

以下是包含四个事件处理器的分散-收集路由器的原理图。它并行执行每个路由，而不是按顺序执行。

首先，我们必须了解在分散-收集组件内可能产生的错误类型。任何错误都可能在事件处理器中生成，导致分散-收集组件引发类型为 Mule: COMPOSITE_ERROR 的错误。仅在每个路由失败或完成之后，S-G 组件才会引发此错误。

为了处理此错误类型，可以在分散-收集组件的每个路由中使用 try scope 。如果 try scope 成功处理错误，那么该路由肯定能够生成 Mule 事件。

下表显示了在配置删除变量转换器时要考虑的字段名称及其描述：

借助 set-payload 组件，我们可以更新消息的有效载荷，该有效载荷可以是文字字符串或 DataWeave 表达式。不建议针对复杂表达式或转换使用此组件。它可用于 selections 等简单表达式。

下表显示了在配置设置有效载荷转换器时要考虑的字段名称及其描述：

我们可以通过 XML 配置代码设置有效负载 -

With Static Content - 以下 XML 配置代码将使用静态内容设置有效负载 -

With Expression Content - 以下 XML 配置代码将使用表达式内容设置有效负载 -

以上示例将把今天的日期追加到消息有效负载“Hi”中。

下表显示了在配置设置有效载荷转换器时要考虑的字段名称及其描述：

以下示例将变量设置为消息有效负载 -

类似地，以下示例将变量设置为消息有效负载 -

在以下示例中，我们将使用 REST 组件和 Mule Soft 提供的名为 American Flights details 的一个公共 RESTful 服务。它有各种详细信息，但我们将使用 GET: http://training-american-ws.cloudhub.io/api/flights 来返回所有航班详细信息。如前所述，REST 与 HTTP 绑定，因此我们也需要两个 HTTP 组件——一个侦听器和一个请求，用于此应用程序。以下屏幕截图显示了 HTTP 侦听器的配置 -

HTTP 请求的配置如下 -

现在，根据我们的工作空间流程，我们采用了记录器，因此可以按如下方式对其进行配置 -

在消息选项卡中，我们编写代码将有效负载转换为字符串。

对于此示例，我们将使用名为国家/地区信息服务的公共 SOAP 服务，该服务保留与国家/地区信息相关的服务。其 WSDL 地址为： http://www.oorsprong.org/websamples.countryinfo/countryinfoservice.wso?WSDL

首先，我们需要从 Mule Palette 的画布中拖动 SOAP 消费，如下所示：

接下来，我们需要配置 HTTP 请求，如下面所示，如上一个示例中所做：

现在，我们还需要配置 Web 服务使用者，如下所示：

在 WSDL 位置的地方，我们需要提供 WSDL 的 Web 地址，如上所述（此示例）。提供 Web 地址后，Studio 会自行搜索服务、端口和地址。您无需手动提供它。

为此，我们需要在 Mule 流程中添加一个记录器，并将其配置为提供有效负载，如下所示：

它是 Mule 错误的一个重要组成部分，将提供有关问题的信息。其表达式如下：

Mule 错误类型组件用于描述问题。它还允许在错误处理程序内进行路由。其表达式如下：

Mule 错误的 Cause 组件提供了导致错误的底层 Java 可抛出项。其表达式如下：

Mule 错误中的消息组件显示有关错误的可选消息。其表达式如下：

Mule 错误的子错误组件提供了内部错误的可选集合。这些内部错误主要由 Scatter-Gather 等元素用于提供聚合路由错误。其表达式如下：

如果 HTTP 请求的状态代码为 401 失败，则 Mule 错误如下：

在上面的示例中，您可以看到 Mule 错误的消息组件。

此类别下的错误是在流程中可能发生的错误。这些错误不太严重，可以轻松处理。

此类别下的错误是无法处理的严重错误。以下是此类别下的错误类型列表 -

自定义错误类型是由我们定义的错误。它们可以在映射或引发错误时定义。我们必须为这些错误类型提供一个特定的自定义命名空间，以便将它们与 Mule 应用程序中的其他现有错误类型区分开来。例如，在使用 HTTP 的 Mule 应用程序中，我们不能使用 HTTP 作为自定义错误类型。

这一类 Mule 错误与 Mule 流相关。每当 Mule 流中出现问题时，Mule 都会引发消息传递错误。我们可以在错误处理组件内设置 On Error 组件，以处理这些 Mule 错误。

系统错误表示系统级发生的异常。如果没有 Mule 事件，系统错误将由系统错误处理程序处理。系统错误处理程序处理的异常类型如下所示：

如果发生系统错误，Mule 会将错误通知发送给已注册的监听器。它还会记录错误。另一方面，如果错误是由连接失败引起的，Mule 将执行重新连接策略。

第一个 Mule 错误处理程序是 On-Error 组件，该组件定义了它们可以处理的错误类型。如前所述，我们可以在 ERROR HANDLER 组件（类似范围）内配置 On-Error 组件。每个 Mule 流只包含一个错误处理程序，但该错误处理程序可以包含我们需要的任意多个 On-Error 范围。在流内借助 On-Error 组件处理 Mule 错误的步骤如下：

以下是 Mule 支持的两种类型的 On-Error 组件：

On-Error Propagate 组件执行，但会将错误传播到下一级并中断所有者的执行。如果它由 On Error Propagate 组件处理，事务将回滚。

Try Scope 是 Mule 4 中众多新功能之一。它的工作方式类似于 JAVA 中的 try 块，在其中我们通常将有异常可能性的代码封装起来，以便可以处理它而不会中断整个代码。

我们可以在 Try Scope 中包装一个或多个 Mule 事件处理器，此后，try scope 将捕获并处理这些事件处理器引发的任何异常。try scope 的主要工作围绕其自己的错误处理策略进行，该策略支持对其内部组件进行错误处理，而不是整个流。因此，我们不需要将流提取到一个单独的流中。

Example

以下是 try scope 用法的一个示例：

在设计异常处理程序之前，此问题非常相关，因为并非所有传输都支持跨国性。

File 或 HTTP 不支持事务。因此，如果在这些情况下发生异常，我们必须手动对其进行管理。

Databases 支持事务。在这种情况下设计异常处理程序时，我们必须记住数据库事务可以自动回滚（如果需要的话）。

对于 REST APIs ，我们应该记住它们应该返回正确的 HTTP 状态码。例如，资源未找到时为 404。

在设计异常处理程序时，我们必须注意消息交换模式。可以有同步（请求-响应）或异步（防火）消息模式。

Synchronous message pattern 基于请求-响应格式，这意味着此模式将期待响应，并且在返回响应或超时之前将被阻塞。

Asynchronous message pattern 基于防火格式，这意味着此模式假定最终将处理请求。

非常简单的规则是，你将根据异常的类型来处理该异常。了解这个异常是由系统/技术问题还是业务问题引起的非常重要？

system/technical issue 发生的异常（例如网络中断）应该由重试机制自动处理。

另一方面， by a business issue 发生的异常（例如无效数据）不应该通过应用重试机制来解决，因为在未修复根本原因的情况下，重试是没有用的。

业务异常发生的主要原因是错误的数据或不正确的流程流。此类异常通常本质上不可重试，因此配置 rollback 不好。即使应用 retry 机制也没有任何意义，因为在不修复根本原因的情况下，重试是没有用的。为了处理此类异常，应立即停止处理，并将异常作为对死信队列响应发送回。还应该向运维发送通知。

非业务异常发生的主要原因是系统问题或技术问题。这类异常本质上是可重试的，因此为了解决这些异常，最好配置 retry 机制。

Mule 隐式地将此策略应用于 Mule 流程。它可以处理我们流程中的所有异常，但是也可以通过添加 catch、选择或回滚异常策略来覆盖它。此异常策略将回滚任何待定的事务并记录异常。此异常策略的一个重要特征是，如果没有事务，它还将记录异常。

作为默认策略，Mule 在流中出现任何错误时实现此策略。我们无法在 AnyPoint Studio 中进行配置。

假设如果没有可能纠正错误的解决方案，该怎么办？一种解决方案是使用回滚异常策略，该策略将回滚事务，同时向父流程的入站连接器发送消息以重新处理消息。当我们想要重新处理消息时，此策略也非常有用。

Example

此策略可以应用于资金存入支票/储蓄账户的银行交易中。我们可以在此处配置回滚异常策略，因为如果在交易过程中发生错误，此策略会将消息回滚到流的开头，以重新尝试处理。

此策略捕获其父流程中引发的所有异常。它通过处理父流程引发的所有异常来覆盖 Mule 的默认异常策略。我们可以使用 catch 异常策略来避免将异常传播到入站连接器和父流程。

此策略还确保在发生异常时不会回滚流处理的事务。

Example

此策略可以应用于航班预订系统，其中我们有一个用于处理来自队列的消息的流程。消息丰富器在消息中添加了一个属性以分配座位，然后将消息发送到另一个队列。

现在，如果此流程中发生任何错误，则消息将引发异常。在这里，我们的 catch 异常策略可以添加一个带有适当消息的标头，并可以将该消息从流程推送到下一个队列。

如果您想根据消息内容来处理异常，那么选择异常策略将是最佳选择。此异常策略的工作方式如下 −

在选择异常策略中，会有多个异常策略，例如 Catch 或 Rollback。如果没有在此异常策略中定义任何策略，它会将消息路由到默认异常策略。它不会执行任何提交或回滚或消费活动。

这涉及一个在独立配置文件中定义的常见异常策略。如果消息引发异常，此异常策略会引用在全局 catch、rollback 或 choice 异常策略中定义的错误处理参数。与 choice 异常策略一样，它也不会执行任何 commit 或 rollback 或消费活动。

对于运行测试套件，右键单击你的测试套件所在的 Mule Canvas 空白部分。它会打开一个下拉菜单。现在，单击 Run MUnit suite ，如下所示 −

稍后，我们可以在控制台中看到输出。

要运行特定测试，我们需要选择特定测试并右键单击它。我们将会得到与运行测试套件时相同的下拉菜单。现在，单击 Run MUnit Test 选项，如下所示 −

然后可以在控制台中看到输出。

要调试一个测试套件，右键单击存放你的测试套件的 Mule Canvas 空白部分。它会打开一个下拉菜单。现在，单击 Debug MUnit Suite ，如下面的图像所示 −

然后，我们可以在控制台中看到输出。

要调试一个特定测试，我们需要选择特定测试并右键单击它。我们将会得到与调试测试套件时相同的下拉菜单。现在，单击 Debug MUnit Test 选项。它显示在下面屏幕截图中。