测试流程依赖性（上）

测试流程依赖性

 

 

今天的主题是“测试流程依赖性”。为了执行模型，通常需要其他资源。这可能是源代码，也可能是对其他模型的依赖。但是在测试模型时我们该如何处理呢？在本文中，我们将仔细研究以下依赖关系：

1. 模型：对执行模型引用的BPMN图的依赖
2. 代码：依赖BPMN中引用的源代码。

我们将了解另一个可以帮助我们进行测试的库：camunda-bpm-mockito。可以在此GitHub存储库中找到此博客文章的示例。

在上一篇文章中，我们仔细研究了一个小的订购过程并进行了测试。现在，我们要扩展它，并包括我们在测试中必须考虑的其他功能：

1. 呼叫活动引用的另一个过程
2. 具有对服务的其他依赖关系的Java委托

对其他BPMN模型的依赖

将BPMN图包含为“呼叫活动”或从代码中启动它们有多种原因：

1. 降低复杂性：广泛的BPMN模型可能会对理解实际流程产生负面影响。因此，有时将技术细节和特性外包给单独的图表很有用。
2. 组件的可重用性：随着自动化流程数量的增加，可以在不同地方使用的功能的数量也随之增加。如果这些不只是简单的服务调用，则可以将这些功能外包到单独的进程中。
3. 启动进程：有时有必要异步启动进程。如果实例结束后要执行其他处理步骤，而不必等待其完成，则可能是这种情况。

这三种情况都导致在测试过程中依赖于另一个过程模型。但是我们应该如何处理呢？

使用参考模型

我们可以在单元测试中使用和测试参考模型。但是，由于以下原因，不建议这样做：

1. BPMN模型必须进行测试，并且测试案例将变得更加广泛
2. 可重复使用的组件经过多次不必要的测试
3. 如果参考模型中存在不同的返回值或错误，流程必须对此进行响应，则这将导致测试用例的大量额外工作
4. 在测试用例中，必须考虑引用模型的依赖性
5. 参考模型中的修改会影响过程的测试用例

使用具有相同密钥的其他模型

可以使用具有相同键的自定义模型来代替使用引用的图，并可以对其结果进行参数化。这需要几行代码：

 

BpmnModelInstance modelInstance = Bpmn.createExecutableProcess()

          .id("callActivity")

          .startEvent()

          .serviceTask().camundaResultVariable("result").camundaExpression(result)

          .endEvent()

          .done();

 

Deployment deployment = rule.getProcessEngine()

          .getRepositoryService()

          .createDeployment()

          .addModelInstance("callActivity" + ".bpmn", modelInstance)

          .deploy();



对于简单模型，这当然是一个可行的选择。但是，在某些情况下会导致额外的工作–例如，如果流程必须响应的参考模型中存在不同的返回值或错误。

模拟使用 camunda-bpm-mockito

可以使用camunda-bpm-mockito库，而不是构建自己的模型模拟。这具有以下优点：

1. 清除针对实际过程的测试
2. 使用的模型中的错误不会影响父流程的测试
3. 可以更轻松地模拟参考模型的行为差异
4. 缩短测试执行时间

现在，让我们看一下我们的订购过程。交付将作为一个独立的，可重复使用的流程外包，该流程被称为“呼叫活动”。

图片

现在，我们将在订单过程中将此交付过程称为“呼叫活动”。但是我们如何在测试中处理呢？我们有两个任务：

 

1. 在测试中模拟交付过程
2. 为交付过程编写单独的测试