Microservice Testing – What is Mocking Dependencies Called?

In my opinion you should mock the webservice calls if this is a unit test, as opposed to an integration test.

Your unit test should not test whether the external webservice is working, or whether your integration with it is correct. Without getting too dogmatic about TDD, note that a side effect of turning your unit test into an integration test is that it's likely to run slower, and you want fast unit tests.

Also, if the webservice is temporarily down or working incorrectly, should this cause your unit test to fail? It doesn't seem right. Your unit test should fail for only one reason: if there is a bug in the code in that "unit".

The only portion of code that is relevant here is ...do something with response.... Mock the rest.

TLDR: Despite the difficulty, you should stub the service and use for client unit testing.

I'm not as certain that the "job of a remote API client is to issue certain calls, no more, no less...", unless the API only consists of endpoints which always return a fixed status, and neither consume nor produce any data. This would not be the most useful API...

You'd also want to check that the client not only sends the correct requests, but that it properly handles response content, errors, redirects, etc. And test for all these cases.

As you note, you should have integration tests that cover the full stack from wrapper -> client -> service -> DB and beyond, but to answer your main question, unless you have an environment where integration tests can be run as part of every CI build without a lot of headaches (shared test databases, etc.), you should invest the time in creating a stub of the API.

The stub will let you create a working implementation of the service, but without having to implement any layer below the service itself.

You could consider using a DI-based solution to accomplish this, with an implementation of the Repository pattern underneath the REST resources:

• Replace all functional code in the REST handlers with calls to an IWhateverRepository.
• Create a ProductionWhateverRepository with the code that was extracted from the REST resources, and a TestWhateverRespository which returns canned responses for use during unit testing.
• Use the DI container to inject either the ProductionWhateverRepository or TestWhateverRepository DLL/class, etc. depending on configuration.

Anyway, unless stubbing and/or refactoring the service is out of the question either politically or practically, I'd probably undertake something similar to the above. If not possible, then I'd make sure to have really good integration coverage and run them as often as possibly given your available test setup.

HTH