The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

388690 (2) [Avatar] Offline
I have a doubt. The book explains how different services should be developed and how they communicate via gateway etc. But often times, we'll have different developers working on different services which may depend on each other - how do we mock the responses of the other services in this scenario?
John C Carnell (44) [Avatar] Offline

There are a couple of different approaches:

1. In my team we always have the URL for the service gateway marked as a configurable property. We can then create a mock endpoint that is called locally.
2. For integration testing we also use a mock server to test our remote invocations. I use Mock Server ( I have also been looking at Mountebak
3. The third option is to a run a local service gateway in Docker and have local copies of the server register locally.

Honestly though we usually write mocks and if we really need to test something for real, we point to a dev server. Parallel development can be tricky, but if anything you establish a contract of the inputs and outputs for the service and then run again mock code.

sguillory6 (28) [Avatar] Offline
Generally, your want to consider wire-mocking approaches (WireMock, Mountebank) and look into contract-driven testing.

Manning has a book on Mountebank, "Testing Microservices with Mountebank" (disclaimer: my colleague wrote it).