Follow the installation example in the intro in order to install and configure an npm script for starting the Mocks Server in your project.
/mocks folder in your project root, containing a
behaviors.js file, and a
You can create as many files as you want in the
mocksfolder, no matter if they contain "behaviors", "fixtures" or both. The Mocks Server will load all of them automatically wherever they are. This structure is only a suggestion.
Now we are going to add a fixture to the
/mocks/fixtures/users.js file, which will be used when GET requests are received in the
/api/users path or our "api mock":
Import your recently created
getUsers fixture in the
/mocks/behaviors.js file and create an "standard" behavior containing it:
The interactive CLI will be started:
Browse to http://localhost:3100/api/users to check that Mocks Server is serving your users collection fixture at the expected url. You should see the response in your browser:
Now we have the mocked the response for the "users" collection. Let's add the fixture for getting an specific user:
Add the fixture to the "standard" behavior:
The Mocks Server is watching for file changes, so your fixtures should have been refreshed automatically.
Browse to http://localhost:3100/api/users/1. You should see the response in your browser:
But... even when you change the user id in the request, (http://localhost:3100/api/users/2) obviously the response will be still the same:
Well, this is the expected behavior of a mock server, but you can add a new "behavior" to change the response:
Let's add another "GET user" fixture, but now it will be always responded with the second user:
And let's add a new Behavior extending the standard one:
Now the Mocks Server CLI indicates that it has two behaviors available.
Use the CLI to change current behavior:
Browse to http://localhost:3100/api/users/2. You should now see the second user:
Browse to http://localhost:3100/api/users. Users collection is also available:
Now you've seen what Mocks Server can do, you can add as much fixtures you need for your development or end-to-end tests, (such as error responses cases, "users" with very long name, another special cases, etc.)
You can combine all your fixtures in as much behaviors as you need, extending them or creating them from scratch.
And, very important, you can easily change the current behavior using the interactive CLI or the REST API while the server is running, which will make your development or acceptance tests environments very much agile and flexible, and not api dependant.