Я бы описал то, что вы хотите сделать, как интеграционный тест, и выходящий за рамки JUnit как фреймворка (JUnit только сейчас погружается в многопоточное тестирование, многопроцессность, конечно, не входит в набор функций).
Конечно, вы могли бы использовать JUnit для запуска таких тестов, но они действительно были бы ограничены бегуном, остальное вы должны сделать самостоятельно.
Другие уже указали на тот фактчто вы обычно высмеиваете или иным образом отправляете искусственно созданные методы потребителю и тестируете то, что производитель производит независимо, на уровне «модульного тестирования».
С точки зрения фактического тестирования взаимодействия между производителем и потребителем,Один из подходов состоит в том, чтобы забыть о межпроцессном тестировании и проверить его внутрипроцессно в одном потоке с помощью какого-либо Inpendency Injection, где производитель отправляет сообщение каким-то фальшивым способом, который просто передает его потребителю без каких-либо дополнительных действий.больше, чем вызовы метода в потоке.
Однако кажется, что вы хотите протестировать вещи, которые могут произойти, с фактическими межпроцессными процессами (условия гонки и т. П.), Что делает этот тест еще более интеграционным.
Чтобы решить эту проблему, вам нужно запустить процесс и подождать, пока он примет сообщение, затем ваш тест скажет производителю, какое сообщение создать, и отправит его потребителю.Тогда ваш тест будет спрашивать потребителя, что он получил (с подходящей задержкой).
Потребность здесь должна быть убедительной для меня, чтобы сделать это.Я бы пошел на полномасштабные автоматизированные приемочные испытания и позволил бы охватить этот уровень интеграции.