I'm trying to get my head around a the development workflow for working with microservices and docker multicontainer applications.

The thing that I'm particularly trying to solve - is getting a good 'live reload' workflow going for development.

For example:

For my frontend I can use webpack-dev-server which automatically reloads the page everytime I save changes. This makes it easy to write front end code quickly - with no waiting for deployments.

However - if the frontend is displaying some data retrieved from a REST API, I'm likely going to be running either a development version of that API (that itself is live reloading with nodemon, or similar) or a mocked API. This is easy enough to achieve with webpack using the proxy configurations for development environment.

For my REST API - I similarly might want to be mocking other microservices. For example if my REST API had a POST endpoint for saving an image - and I'm going to save that to an AWS S3 bucket, via the aws-sdk, I'm likely to want to be mocking that functionality.

Essentially - what it looks like - is that for every (or most) microservices - I'm also going to want to create a mock version of it.

What I imagine my workflow would look like, is something like this:

  1. On the front end I create a button that submits an image to the backend. I check that the POST request is being made properly.
  2. On my REST API, I create an end point that receives the POST request. I click the front end button and check that the backend is recieving it.
  3. I create a backend microservice to make AWS SDK calls. I wire it to point to a real development AWS bucket. I wire the POST endpoint to submit the image to this microservice. I click the frontend button and check that it ends up in the S3 bucket.
  4. But submitting this image is too slow, so I create a mock version of the AWS SDK service. I switch the REST API to use that one instead.
  5. On the frontend I now write some functionality to display a 'image saved!' confirmation message.

My question is:

  1. Is this a standard way of doing things, or am I going way off base?
  2. Is there a way in docker to quickly switch between whether I'm using the real microservice or the mocked one?
  • you're talking about when you are coding, not for unit tests?
    – Ewan
    Jan 25, 2018 at 21:30
  • @Ewan - I mean - I think it would be a fair enough answer to suggest perhaps I doing it wrong by not doing unit tests. But yes - I mean when I'm doing coding.
    – dwjohnston
    Jan 25, 2018 at 21:35
  • From a unit test perspective, I don't think the fact that these are microservices matters. Code is code. If you're trying to test the microservice end-to-end, that's an integration test, not a unit test. I don't particularly care what vocabulary you use, but it might be helpful to define your terms more specifically. Mocks are something I'd normally see used in unit testing, not integration testing. See en.wikipedia.org/wiki/Mock_object Jan 25, 2018 at 21:40
  • I think its somewhat of a survey. I would normally run against either a dev server or a local instance. I don't think i would count these as "mocks" but they would be pointing at a dev AWS account
    – Ewan
    Jan 25, 2018 at 21:50
  • 1
    We are happy using getsandbox.com for that purpose Jan 26, 2018 at 20:33

1 Answer 1


Yes, mocking out your external services is a valid idea and is often the only way to test unmodified code without a real physical instance.

It is not as accurate as using a test instance of the the real thing since your mocked behaviour is:

  • Your understanding of the external service, not the actual behaviour of the external service
  • Lags behind changes and updates of the external service
  • Doesn't have representative timing or performance implications which is often of interest for testing

They are a good way to quickly perform 'did I just break something', 'do I handle return errors and the unexpected' and 'how sensitive am I to external service performance' tests. You gain system test flexibility and coverage at the cost of the maintenance costs.

Many a website has gone down for lack of such testing but this isn't the only way to get test coverage for these things as commentators have pointed out by using unit tests.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.