Services: To mock or not to mock?

When testing an application at the integration level, there are at least 2 paradigms commonly used. Here we will briefly discuss:

  • End-to-End (e2e) testing on a Test environment
  • Isolated testing using mocked services

On an e2e testing environment, services are fully deployed and exist with the proper configuration necessary to talk to the app and/or services. This is what many testers may associate with when testing.

When working with an app using mocked services, this allows us to tailor the behavior we return to the consumer application. This is desirable due to 3rd party availability restrictions, API quotas, a non-stable service, or just lack of control and the negative effect this has on testing the app in an Integrated environment.

So then I should use mocks, right?

It depends! I prefer to use an actual service for running sanity checks and any automated functional tests. If you can create multiple testing environments, the one closest to the Production application should be configured with full non-mocked services. The reasoning is that you want to have as close a mirror to your application as possible with little-to-no gotchas.

If you are a developer of an app you may want to take the mocked services approach. With this, development is not compromised because of reasons out of your immediate control. Mocking services also allows you to better execute a wider array of paths between the app-service contract. Please note:┬ámocking can also be performed in unit tests themselves — and in many cases may negate the need for standing up mock services in your local environment.

Is that it?

Not really. Since there are minimal rules in creating software, you may encounter an environment which is used for e2e testing but with mocked services. I wouldn’t suggest this┬ásince you get less of a full picture which is provided when using a truly integrated e2e environment.