我将描述您希望做的集成测试，并且超出了JUnit作为框架的范围（JUnit现在才涉足多线程测试，多进程当然不在特性集中）。
当然，您可以使用JUnit来运行这样的测试，但是它们实际上仅限于运行者，其余的工作您必须自己完成。
其他人已经指出了这样一个事实，即您通常会模拟或以其他方式向使用者发送人工构造的方法，并在“单元测试”级别测试生成器独立生成的内容。
就实际测试生产者和消费者之间的交互而言，一种方法是忘记进程间测试，并通过某种依赖注入在一个线程上的进程内测试它，其中生产者通过某种虚假的方式发送消息，该方式只是将消息传递给消费者，而没有比线程内方法调用更多的东西。
然而，您似乎希望测试在其上实际的进程间的东西（竞态条件等）时可能发生的事情，这使得这更像是一个集成测试。
为了解决这个问题，你需要启动进程，等待它接受消息，然后你的测试会告诉生产者要创建什么消息，生产者会把它发送给消费者，然后你的测试会询问消费者它得到了什么（有适当的延迟）。
这里的需求必须是我必须做的。我会去全面的自动化验收测试，让它包含这个集成水平。

你应该看看XHarness，我相信它能满足你的需求。我最近用过它，它在当时的项目中效果很好。
从它的页面：
“XHarness是Apache Ant的系统测试工具。它允许开发人员以XML的形式将其产品/系统测试描述为Ant构建文件的一部分，描述组成测试用例的任务和流程以及它们的预期行为。它具有强大的流程管理功能，扩展了现有的Ant流程任务（exec、java），以允许java和本机进程的异步执行（例如，用于客户端-服务器测试）、多个进程之间的同步以及进程和任务输出（stdout/stderr、文件输出，以及超时等）上的复杂Assert。“

我建议使用模拟对象，然后你可以测试生产者和消费者独立地模拟另一个。
你也可以测试这两个通信机制，但我希望这是由第三方提供的？
请参阅Mockito、jMock、EasyMock

你在第1点中所谈论的并不是一个真正的单元测试场景。在一个完美的单元测试中，你不会担心谁在生成消息，谁在使用消息。你的一个测试用例将集中于想象（或模拟）您从一个有效的生成器接收到不同的消息，您的测试用例将测试这些消息是如何被正确使用的。你所看到的更像是一个集成测试。无论如何，我所做的一些陈述可能是主观的。你可以使用jMock，easymock框架来满足你的模拟需求。

这远远超出了单元测试的范围，完全属于集成测试。
我会建议测试什么，你可以嘲笑出你的通信层与每一块分开。
我过去在这种情况下所做的是在测试中启动一个单独的线程，启动一个模拟接收器/发送器。在主测试中，我然后做发送器/接收器部分。在实践中，这意味着这是充满延迟的，以确保事情开始在正确的顺序，这变得非常慢，所以你只想这样做，以测试拼图的碎片适合，并尽可能少地对其进行功能测试。
我验证了所需的行为，并在离开测试之前终止了帮助线程。
这可以测试很多东西。使用单独的进程（和主机！）进行测试是一个真实的的痛苦。需要永远的时间，我会将其限制为手动测试。

回答问题2和3：
关于架构，我会考虑将创建进程的责任委托给操作系统或主机。就像在这个线程Executing Maven task from shell script and getting error codes中一样，在您选择的shell脚本环境中使用同步机制来验证错误。即使在CI/CD管道中，通常也有一个脚本在操作系统上运行，理论上您可以修改它。