测试流程依赖性（下）

测试流程依赖性（下）

对源代码的依赖

现在让我们看一下如何处理代码依赖性：

用模拟替换所有依赖
提供整个背景
提供具有依赖性的特定类

如果所有依赖关系都被模拟代替，则测试将失去其有效性。相反，提供整个上下文会错过单元测试的目标，对于大型应用程序将非常耗时，并且会导致更长的测试运行时间。因此，解决方案必须是最后一点。但是应该提供哪些类，哪些应该用模拟代替？

让我们看一下使用发送取消任务中使用的Java委托并添加邮件服务的示例：

@Component

public class SendCancellationDelegate implements JavaDelegate {

private final MailingService mailingService;

@Autowired

public SendCancellationDelegate(MailingService mailingService) {

this.mailingService = mailingService;

}

@Override

public void execute(DelegateExecution delegateExecution) throws Exception {

//input

final String customer = (String) delegateExecution.getVariable("customer");

//processing

mailingService.sendMail(customer);

//output

delegateExecution.setVariable("cancellationTimeStamp", Instant.now().getEpochSecond());

}

该委托读取过程变量，使用邮件服务发送取消，并将取消时间写回到过程中。在测试用例中执行此委托绝对是一个好主意，因为它增加了测试的重要性。但是，发送邮件没有用。

总结：如果可能，应执行从图中引用的类。反过来，应该嘲笑它们的依赖性。

为此，我们将测试扩展如下：

1.创建一个MailingService模拟：

@Mock

private MailingService mailingService;

2.将模拟传递给委托人：

Mocks.register("sendCancellationDelegate", new SendCancellationDelegate(mailingService));

3.执行sendMail（）时不执行任何操作：

doNothing().when(mailingService).sendMail(any());

4.检查邮件服务是否被调用：

@Test

public void shouldExecuteCancellationSent() {

when(testOrderProcess.waitsAtUserTask(TASK_CHECK_AVAILABILITY)).thenReturn(task -> {

task.complete(withVariables(VAR_PRODUCTS_AVAILABLE, false));

});

Scenario.run(testOrderProcess)

.startByKey(PROCESS_KEY, withVariables(VAR_CUSTOMER, "john"))

.execute();

verify(testOrderProcess)

.hasFinished(END_EVENT_CANCELLATION_SENT);

//verfiy execution of mailingService

verify(mailingService, (times(1))).sendMail(any());

verifyNoMoreInteractions(mailingService);

}

在复杂的上下文中，可能很难跟踪测试用例中使用的所有模拟。相反，将它们外包给工厂类更有意义，以便也考虑彼此之间的依赖关系。

结论

使用camunda-bpm-mockito库，还有更多可能。例如，您可以模拟要关联的消息，也可以模拟Camunda查询的结果。所有这些功能使测试更复杂的过程变得更加容易。

这篇博客文章是测试流程依赖关系的第一步。代码和模型通常紧密地联系在一起，这也影响了我们测试用例的范围。但是，本文中显示的示例和建议可以帮助简化您自己的测试并减少工作量。

但是我们怎么知道我们编写的测试是否足够并且涵盖了过程的所有必要部分？我们如何监控呢？我们将在下一篇文章中讨论这个主题。

测试流程依赖性（下）

相关教程