Применение камунды в тестировании

Добрый день. Не подскажете, у вас нет видеобзоров для тестировщиков, как тестировать продукт, когда вся логика процесса на камунде написана, как можно изменять данные в камунде, как остновиться на каком-то кубике, чтобы смотерть какие входные данные пришли и как их изменять?

2 симпатии

@nasynova91 Здравствуйте!

Для автоматизированного тестирования используем следующие решения:

Camunda BPM Assert: GitHub - camunda/camunda-bpm-assert: Easily test/drive Camunda BPM processes and cases and assert their status. - проверка процесса и делегатного кода по различным сценариям/исключениям (все вызовы бизнес-сервисов можно “замокать” с помощью Mockito)
Camunda BPM Process Test Coverage: GitHub - camunda/camunda-bpm-process-test-coverage: Community Extension Helper library to visualize which parts of a BPMN process have been covered by a unit test - Показывает покрытие элементов процесса тестами, на выходе диаграмма процесса с подсветкой покрытых тестами элементов

Для ручного/пользовательского тестирования можно использовать Cockpit - в нем можно подставить/удалить переменные, поместить в них необходимые значения.

P.S. По теме автоматизированного тестирования планируем записать видеоурок.

Спасибо за ответы. Еще вопрос, если в процессе сервис таска делает запросы на внешние сервисы и получает ответы, как проверить запросы, например на ответ 500? Привлечь Постман? Интересует ручное тестирование. В кокпите как изменили данные, что дальше надо делать, чтобы проверить процесс на новых данных - заново стартовать процесс?

Ответ 500 скорее всего (если используется коннектор или java delegate, и если разработчик не обернул вызов в try/catch или не обработал его с помощью BpmnException/ErrorMessage) приведет к появлению исключения (Exception). А оно, в свою очередь либо будет выведено пользователю (в синхронном режиме), либо выработает инцидент, который будет виден в Cockpit (в асинхронном режиме). Это же касается и других ответов.

Не зная структуры вашего процесса, рискну предположить, что если вы хотите тестировать такие сценарии вручную, необходимо предусмотреть wait states. Это некие точки остановки, когда исполнение процесса останавливается, данные записываются в базу. Примеры таких wait state: User task, Receive Task, Timer Event, Message Catch Event и тд. Тогда получится сделать так:

  • Дождаться нужного wait state (например, пользовательской задачи)
  • В cockpit подставить нужное значение
  • Продолжить исполнение

Спасибо. да, в процессе используется делегэйт.
А через постман могу обратиться к конкретному кубику в процессе, чтобы поменять параметры на другие для проверки всевозможных вариантов ответов? Если да, то как обратиться к кубику? вопрос актуален и для стрелок, можно ли к ним обратиться напрямую с постмана используя какой-то ID?

Да, легко. у Camunda все, что доступно через TaskList, Cockpit - доступно через REST API:

Например, завершение задачи:
https://docs.camunda.org/manual/7.14/reference/rest/task/post-complete/

Я встречал сценарий тестирования, когда вместо пользователя использовался Postman:

  1. Стартовали процесс, получили process instance id
  2. Получили текущую задачу, завершили, проверили ответ
  3. и т.д.