Например, в ситуации с загрузкой картинок, в дефереды, которые возвращает аякс запрос, можно сохранить информацию о самом аякс запросе и о количестве перезапусков.
В качестве языковой конструкции я видел такое в лиспоподобном языке, разрабатываемом в JPL для космических роботов.
И вот во всяких промышленных scada это наверняка востребовано, и там явно не лисп.
Проблема в понимании пунктов «протестировать каждый workflow по сценариям использования» и «написать автоматические тесты»
В юнит-тестировании есть готовые входные данные и оижидаемый результат. Всё кристально понятно. Сунуть данные сравнить результат.
Тут же вместо этого на входе некая ситуация и ожидаемое поведение. И то и другое процессы. Причом они переплетены так, что активную роль играют попеременно тестируемый и тестирующий. Да и инициирует процесс (в реальности) тестируемый.
Например, ситуация (поведение теста):
2. получить номер телефона
3. набрать его и посигналить об этом
5. подождать < N сек
6. обломать соединение, посигналить об этом
9. подождать немного и посигналить таймером
11. просигналить об освобождении ресурсов
Ожидаемое поведение юнита:
1. отправить номер телефона
4. получить сигнал и отметить его как зашибись
7. получить сигнал облома, расстроиться
8. повесить номер на таймер
10. дождаться таймера, засунуть номер в очередь
12. дождаться освобождения ресурсов
13. повторить пункты 1-7 N раз
7n+1. сделать грустное лицо, пометить номер телефона как плохой
