Use Cases
In summary, sometimes the flow we need is too difficult to reproduce from the actual backend.
Testing errors and edge cases on third-party APIs
Mockaton lets you trigger states that might otherwise be impossible to test when using third-party APIs.
Testing recovering from an error
For instance, on a design review, you might need to demo what
happens when API recovers from an error. So you could start
with an autogenerated 500 response, and then toggling
it OFF to a 200.
Testing slow to generate resources
Similar to testing error recovery, when polling APIs, say, a slow
to generate backend resource. Begin lets say with a 204
(No Content) mock, and then switch it over to a 200.
Testing sensitive data APIs and resources
Say you need to work with sensitive documents you are not allowed to see, such as PII (Personally Identifiable Information).
Testing all permutations
Besides helping to set up screenshot diffing tests, (see pixaton-tests/ in the repo), developing against comprehensive states help to spot inadvertent regressions. For example, see these ColorCards below.
Working around unstable dev backends
If you are a frontend developer you might be spending too much time syncing the database and spinning up dev infrastructure. And sometimes blocked by its instability.
Also, sometimes you could be blocked by waiting for backend APIs to be ready. So having a real HTTP server helps to write frontends ahead of time.
Time travel
If you commit the mocks to the repo, you won’t need to downgrade backends when checking out long-lived branches or bisecting bugs.
Standalone demo server
You can deploy a Mockaton instance with your built SPA.
For that, put the built assets in config.mocksDir.
The repo includes a demo which builds the frontend app and runs a docker container with Mockaton as backend.
git clone https://github.com/ericfortis/mockaton.git --depth 1
cd mockaton/demo-app-vite
make run-standalone-demoDashboard: http://localhost:4040/mockaton