Pavel

Достаточно лаконично получилось.

Согласен. В размышлениях действительно можно завязнуть. Лучше чтобы "features" приходили из реальной необходимости на практике.

размышление вслух: Концептуально, мы тестируем конкретного агента, его внутреннаяя реализация по хорошему не должна нас интересовать. Если нам нужно протестировать "внутренних агентов", мы их должны так же отдельно тестировать. А т.к. "внешние события" скорее всего они будут получать через этого агента или какой-то "ящик" который он им передает при создании, то значит и мы в сценарии косвенно или прямо сможем влиять на события..

Мне тоже кажется, что вторая идея более "интересна", выглядит более гибкой для дальнейшего развития. Небольшой доп. вопрос. А что будет если тестируемый агент создаёт внутри "дочернюю" кооперацию?

Кстати это неочевидная особенность, возможно которую потом стоит отдельно отметить. Что шаги не последовательны. М-м.. написание таких тестов... это надо обдумать )

Ok. Т.е. это не завершение текущего, а "мостик" к следующему шагу..

Возможно ли это выловить на этапе компиляции или какой-нибудь exception на этапе исполнения?

Прошу прощения. Опять присмотрелся к примеру "в общем" и думаю может даже у нас тут не when_ а then_ ? Или какой-то check_ (test_)? Т.е. сейчас получается что у нас в when_ сформилирована сама проверка, а не условие "запуска" (или триггер, для которого название when действительно более подходящее). У нас получается сформулирован результат который мы ждём (проверяем). scenario.define_step() .impact<> .check() .impact<>() .check(); scenario.define_step() .impact<>() .test() .impact<>() .test() scenario.define_step()...