@franz in some point in time, of course depending on the scale of a project, everyone comes to the moment when there are to many services to run on a single machine (testing, source control and builds/deployments).
One of the main goals in designing microservice (and microservice system), from my perspective is to have microservice as a building block, decoupled as much as possible with clear boundaries (API) and limited complexity that in the end allows microservice to be quality unit tested.
So with “well” designed microservice, unit test should cover most of the needed tests for this building block.
Of course end to end test is required to test laks in mockings done in unit testing and flow of real data.
Also there could be situations where microservice can not be completely unit tested and requires/depends on one or more microservice to test.
In my expirience, in most cases, this was a lack in the design itself.
So level of quality of unit testing is indicator for level of decoupled-ness ( I do not think this word exists in english it 
) and complexity.
Tnx to Lagom there are so many great testing features provided.
End to end testing is something we do in test microservice system environment (so not on the single machine but on cluster). But with good quality unit testing done, end to end tests are less complex.
Also increasing number of microservices is not just a question of testing but also maintaining source and builds/deployments.
The next logical step is Multiple builds
This allows you to decouple “runAll” build to build per service.
You can also notice in the documentation that you can include other builds in “local build” that alows you to unit test with multiple builds. Personally did not used this very often.
From build/deployment perspective we are doing separate builds per api project, util project, protocol project and impl project.
- api - service API
- util - util helper functios (reusable code and nothing service specific)
- protocol - specific protocol related staff (xsd, json schema,…), basically api dependency
impl - service IMPL (using api, util and protocol as its dependency)
Source, for all, is stored in version control repository
Releases for api, util, protocol are stored on our local repository (artifactory).
Impl releases (builds) for stored depending on the deployment (bintray, docker repos,…).
I think this is more info that you requested but I beleive it is connected.
Br,
Alan