"Fixtures handlers" are the pieces at charge of handling the fixtures declarations, discerning whether a request has to be handled by a fixture or not, and sending responses when appropriate.
The mocks-server includes only one fixtures parser by default, which accepts fixtures declared in the format described in the "fixtures" chapter, but you can add your own fixtures declarations formats.
This feature, combined with the plugins development, gives you the possibility of extend the mocks-server with almost every new feature you want.
A fixture handler should be defined as a
This static method will be called when mocks files are loaded. Every object found in the
mocks folder will be passed to this method, in order to let the fixture handler recognize if it is a fixture that he is able to handle or not.
This method should check the received object, and return
true if it recognizes it as a fixture, or
false if not.
static get displayName()#
This static getter should return the name of the fixtures handler, which is useful for debugging purposes.
recognize static method returns
true, then the constructor will be called passing again the fixture, and the mocks-server
core instance, which contains methods described in the programmatic usage chapter.
This method is called to check if the fixture should handle a certain request. It receives the
express request object as argument, so you can check the
The method should return
true if the fixture is at charge of handling the request, or
false if not.
handleRequest(req, res, next)#
requestMatch method returns
true, then this method will be called passing the
Then, this method should send the correspondent response based on the fixture properties. Check the
express documentation to know how if you are not already familiared with it.
This project works well with
@hapi/boom, so you can use it for responding http errors (simply call
next(Boom.badRequest()), for example)
This getter should return an unique id for the fixture, different to all other fixtures. It should be calculated based on the fixture properties to make it persistent, or, in other words, it should return the same value for the same fixture each time the mocks server is started.
This id should be unique from the point of view of the fixture properties that will make it match and response to an specific request and not to others. (For example, if your fixture format includes "url" and "method" properties, these should probably be used to calculate the
requestMatchId). So, all fixtures at charge of responding to the same request should have the same
This getter should return an object describing what makes this fixture handler to match a request or not. It should be like the
requestMatchId, but more "human friendly".
This getter should return an "human friendly" response preview. This response getter is used only for debug and display purposes, as the real response should be sent by the
Here you have an example of how a fixtures handler should be defined:
Now, after adding this custom fixture handler with the
addFixturesHandler method, Mocks Server will accept fixtures defined as:
By the moment, custom fixtures handlers can be added to the server only programmatically. In next releases this can be done easier through a configuration file in the root folder of the project.