[AndrewHampton]

Yeah, this is pretty much what we do. We only use test suites for the backend apps which only expose an API. They just stub out calls to other services.

However, our front end apps is where we're running into trouble. The people on the front end want to run through everything in their browser to make sure everything works and looks good.

We use docker and fig (now docker-compose) to run all our apps. So we've been talking about using compose's new external_links feature to link each app together.

I hadn't heard of moutebank though, so thanks for the link!

[tekacs]

Mountebank/mocking is a great solution when your components are too big to spin up new ones for 'free'.

It's exactly because Docker-based components end up so big that it seems hard to believe in the viability of that approach to microservices though. :/

It's a great stopgap/migratory step, though.

[bbyars]

I think some level of integration testing is always a good thing, but spinning up all dependent services just so you can test yours leads to all kinds of problems, even in microservices. You end up with cascading dependencies.

At scale, some level of stubbing is required to test.

[tekacs]

Agreed.

We _partially_ solve this problem by letting you run a dev cluster that you can use for services which are awkward to run locally, but stubbing/mocking definitely has a place in automated testing, certainly.