CODEWITHSUNDEEP
javatestingintegration-testing
Nick DeFazio
Nick DeFazio

Reputation: 2432

Using live endpoints vs using mocked endpoints in integration tests

Recently my colleagues and I have been writing integration tests for a Java project. Most of these integration tests require at least one SOAP web service call, LDAP query, or something else that relies on endpoints we do not necessarily have control over. Some of these SOAP/LDAP calls use libs that are also still in development.

What this ends up meaning is that our integration tests will sometimes fail during a build when a machine goes down, a lib changed, or an endpoint was altered. After doing some research, I have noticed that it seems fairly common that people use live endpoints in integration testing, but I have also found articles about why using live endpoints can be harmful(http://martinfowler.com/articles/nonDeterminism.html#RemoteServices) .

I am wondering what makes more sense when creating integration tests: mocking all endpoints, or using live ones? It seems that using live endpoints, especially when unreliable, makes tests non-deterministic. However mocks seem like they will only take you so far, and you won't be able to test what happens in a production-like environment. Are integration tests made up of pure mocks valuable for verifying anything aside from regressions?

Upvotes: 3

Views: 2614

Answers (2)

Radu Rosu
Radu Rosu

Reputation: 41

You should definitely try to mock your endpoints. There are several reasons for doing this:

  • performance matters,
  • no stress on production environment, or
  • if some bugs are detected, why break the production environment?

You can find more about this issue in this blog.

Upvotes: 2

Jeff Storey
Jeff Storey

Reputation: 57162

When you mock and enpoint, it is very important that you accurately mock the endpoint. If you don't, your tests can lead to you falsely believe that you will can properly integrate with the service. The fact that you are working with endpoints that are changing would seem to make this difficult.

Whether you do it at an integration testing or acceptance testing level, you should have tests that interact with the real endpoint, otherwise you won't know if integration actually works.

In your case, for example, if a library changes or an endpoint is altered and your test fails, that is in fact a failure in integration, so that's a good thing to detect. If the machine goes down, you could detect that in your test and report the test as skipped rather than failing in this.

So in this case, I would use the real service to ensure your software properly integrates with the third party components.

Upvotes: 5

Related Questions