Mock an API for development purpose (no testing)

Question

If I want to implement a connection from my software to an API, which is documented but not accessible yet, what is a common way to imitate the API until it is available?

My first idea was to mock the HTTP client and conditionally return responses (depending on the request data). But whenever i google for "mocks", it always involves testing somehow. It feels like, I am on the wrong track. I don't want to test it. But i want some code, that behaves like the API later. Also i don't think i should mix test and devlopment space somehow (in my architecture ist strictly separated)

Also: What to do with this temporarly required code? I think it should not go in my codebase, or should it? On the other side, if I would have this code once, it can be used to be independent from the original API that might be not reachable at any time.

Since tests later on also involves a lot mocking API calls, is there a smart way to "reuse" it?

Any suggestions?

• Ben Cottrell: Testing is part of development - it isn't possible to write code without doing some kind of testing. Also, stop thinking of this mock as "temporary" as that sounds as if you plan to throw away the mock after the API is available. Don't throw it away. Throwing away a mock amounts to throwing away knowledge about how the API is expected to work, which is incredibly valuable for other future developers (or your future self) when the requirements change, or a bug is found, or the API changes. You have full control over your mock, but you will never have control over the API.
• bdsl: "I don't want to test it. But i want some code, that behaves like the API later." If you don't test it then you'll never know how it behaves and it wouldn't matter. I guess what you mean is you want to test it manually, not in an automated test. Maybe worth editing the question to say so if that's right.

Answer 1

You have several connected questions. Have are some short answers.

• Ignore the fact that googling mocks mostly gets you pages about testing. Why? Because ‘what is it commonly used for’ does not answer the question, ‘is this a good use’?
• Do you need something to work against whilst waiting for your API to be delivered? Yes you do.
• Is a mock a good solution?
  • Probably yes. Think of mocks as a ‘low code’ solution. It allows you to work with known example responses for a minimal amount of coding.
• Is putting it in your codebase right now okay? Yes, it's what you need to do to write code. Delivering code now is good. Not delivering code now because you are waiting for something is not so good.
• Is there a way to make this ‘temporary’ code less temporary and/or gain some benefit from it later on?

This last question is less black and white and it depends on your working environment and what kind of configuration you can do.

• If you can configure your application to recognise being in a test-without-external-dependencies mode from being in use, then you can continue using your mock for unit testing even after the real api is available.

Underlying principles

Some of the beliefs that drive the above answers are:

• Delivering working code is the primary measure of progress, so paying an overhead to help you deliver is better than being stuck
• Using tools (like mocks) that someone has already written and tested is cheaper than writing and testing your own.
• It is very good to be able to test parts of a distributed application independently because the network is not reliable and networks calls are much much slower than not-networked calls. So relying on the network makes your testing much slower.