What is a hosted mock service, and what does a team give up by adopting it?
answer
- somebody else runs the stub
- replies live in an account
- no pull request behind an edit
- shared address, shared mapping set
- convenience bought with custody
basics
~20 sA hosted mock service is a stub server a vendor runs for you. Its canned replies live in an account on their platform, reachable at an address they control. What you give up is custody: review, rollback and availability.
solid answer
~40 sA mock service is a program that impersonates an API your code depends on, matching each incoming request against rules and returning a canned reply. A *hosted* mock service is that idea sold as a product: the vendor runs the server, you define the replies in an account, and you get an address to point tests at. The appeal is that nothing has to be installed, started or kept alive by your team, and everybody can reach the same stand-in. The cost is custody. Because the rules live in an account rather than your repository, a change to them has no diff, no reviewer and no revert; every branch shares the same set; and a vendor outage turns your build red for a reason no commit of yours explains or fixes.
go deeper
Be able to define a hosted mock service in a sentence and say where its replies live. That location, an account rather than your repository, is most of the answer.
Contrast it with a stand-in you run: who may edit, whether a change is reviewed, whether definitions travel with a branch, and what undoing a change means in each case.
Give the routing rule you would actually apply — local stand-ins for the fast suite, hosted only where being shared and always-on is the point — plus the safeguards you would add.
Weigh convenience against custody for the whole organisation, exit cost included, and set the policy for which delivery paths may depend on a stand-in you do not operate.
## What a hosted mock service is A **mock service**, also called a stub server, is a program that impersonates an API your software depends on. Instead of calling the real seed-bank inventory API, your application calls the stand-in, which matches the incoming request against a set of rules and returns a canned reply. Those rules and their replies are usually called the **mapping set**, and they are the whole substance of the thing: a mock service with no mappings does nothing at all. A **hosted** mock service is that same idea offered as a product. A vendor runs the server; you sign up, define your replies inside an account on their platform, and get back an address to point your tests at. Nothing is installed, nothing is started, and nothing has to be kept alive by your team. ## Where the replies live, and why that is the whole question The difference that matters is not that the server sits somewhere else. It is that the *mapping set* sits somewhere else: - With a stand-in you run, the definitions are files in your repository. They are reviewed in a pull request, they travel with a branch, they are versioned alongside the code that depends on them, and undoing a change is a commit. - With a hosted service, the definitions are the state of an account. They are changed by whoever can sign in, they are shared by every branch at once, and undoing a change means a person re-applying an earlier state by hand. Everything else follows from that. Ask the questions in that order: where do the definitions live, who may change them, and how do I get a known state back? ## What a team gives up - **Review.** A change to a hosted mapping set has no diff and no approver by default. It happens, and then it has happened. - **Rollback.** There is no revert. Restoring means somebody re-creating a known-good state, which requires that a known-good copy exists somewhere you control. - **Attribution.** *Why does this reply say that?* is answerable from a commit message in a repository, and frequently unanswerable in an account. - **Hermetic tests.** The suite now needs the network, the vendor's availability and a valid account. A build can go red for reasons no change of yours explains and no commit of yours fixes. - **Isolation.** Because everybody shares the account, a colleague's edit for their branch is your edit too, and parallel runs needing different replies for the same request collide. - **A cheap exit.** The address, the format and the conventions are the vendor's, so leaving costs roughly what you invested in clicking rather than committing. ## What a team gets The trade runs in both directions, or these products would not exist: - The stand-in is always up and reachable from anywhere, so a mobile app, a partner's engineer or a demo laptop can use it without running anything. - Nobody on your team maintains a process, an image or a certificate for it. - People who do not write code can be given a way to adjust a reply, which is occasionally exactly what a product or support colleague needs. - It exists before your infrastructure does, which is why hosted mocks show up early in a project and during integration work with an external partner. ## A reasonable default For most teams the honest split is: stand in locally for everything the fast test suite touches, and reserve a hosted service for cases where being shared and always-on is the actual point. If you do adopt it, buy the cheap insurance straight away: - Export the mapping set on a schedule and commit the export, so a change becomes a diff your team can read. - Restrict who may edit, and know by name who those people are. - Keep the address in configuration rather than scattered through tests, so leaving is a settings change rather than a search. - Decide, before an incident happens, what a build should do when the address does not answer. ## The sentence to say in an interview A hosted mock service is a stub server operated by a vendor, whose canned replies live in an account rather than in your repository. That buys availability and convenience, and it costs you review, rollback, isolation, and the ability to fix your own outage. Everything else about the topic is a consequence of where the definitions are kept.
- How is a hosted mock service different from an in-process test double?An in-process double replaces an object inside your program, so nothing leaves the process and the substitution is invisible on the wire. A hosted mock is a real server answering real requests at an address, so your code exercises its actual client, serialisation and error handling. It also lives outside your process and outside your repository, and that latter fact is where most of its costs come from.
- Your team wants to adopt a hosted mock service. What do you insist on before it ships?Named edit rights, so the set of people who can change replies is known and small. A scheduled export committed to the repository, so a change is a diff and a restore is possible. The address held in configuration rather than scattered through tests. And an agreed answer to what a build should do when the service does not respond.
It is the difference between a spare key cut in your own workshop and a spare key held behind the letting agent's counter: both open the door, but only the key you cut is a key whose copies you can account for.
saying these in an interview costs you the question
- Calling it a mock library rather than a running server
- Assuming the hosted replies are versioned with your code
- Thinking a hosted mock reads from the real service
- Believing each branch gets its own copy of the replies
- Ignoring that the vendor's outage becomes your red build