This is a good question, and I’ll answer it in parts, although I am not a Play expert.
1 – Writing Tests
I would recommend testing modules in isolation to avoid the exponential explosion of necessary test cases. To this end actors are a very nice abstraction because you can trivially mock any actor by injecting a TestProbe
instead of the real ActorRef
. In a cluster you will typically want to look up services on other nodes, which means that in a test you construct your probe and inject its path (probe.ref.path
) instead of the path you would look up in the production system.
The second aspect concerns integration tests for which you want multiple services to participate. In this case you don’t need to start a “proper” cluster involving multiple JVMs, you can just spin up multiple ActorSystems within your test and have them communicate on "localhost"
.
2 – Development Deployments
It is not necessary to run multiple instances of sbt, you can just create a suitable Main class which starts all required ActorSystems within the same process, just like for the tests as mentioned above.
3 – Node Role Management
The ActorSystem managed by Play will typically have a “frontend” role. In addition to that one you can start more systems with different roles, which are not Play applications by themselves. Triggering different behavior—starting different services and initiating different activities—makes sense based on the node’s role, we do that ourselves in tests and real applications.
On the question of disabling certain routes for certain roles I do not know enough to answer.