stubborn-server
NodeJS Stub server for test and dev purposes
Is your backend stubborn?
Features
- Mocking with static json
- Mocking with dynamic request handlers based on Express requests
- Storing/accessing a memory database
- Separate database per namespace
- Reset a db at anytime with default values
- Usage of aliases to get alternate mock responses (allow scenarios flexibility)
- Integrates well with any test framework
Just show me code!
Ok... create a stubborn.js
file where you want to use it content might look like
moduleexports = logMode: 'all' // can be 'all', 'info', 'mock', 'warn', 'error' or 'none' namespace: '' // help switching between different senarios pathToMocks: 'mock-examples' // mock folder relative path servePort: 8059 includes: '__custom/express_handlers' // List of files into the mock folder where the express app will be exposed for custom handling fallbacks: // using "path" key tells that we refer to a local file url: '/assets/*' path: '/path/to/static/folder' // using "target" key tells that we refer to an http location and is treated as a server proxy url: '/*': target: 'localhost:3000' // using "mock" key tells that we refer to an existing mock, a direct regex can be used here url: /api\/path\// mock: 'api/path/__wildcard__/more/paths' ;
or a stubborn.json
file
Then write your initiator like the one given in demo.js
or in tests/...
Might look like this :
const stubbornServer = ;const stub = ; stubstart/* config to extend ./stubborn.js if required */; // from this point, you may run your queries stubconfig; // from this point, you may run other queries stub;
I also have the intention of having this available directly from the command line.
Write your mocks
Mocks can be specified in three ways:
- Attaching express handlers
- Including express handlers
- Configuration-driven
The way you choose depends on the needs of your project. You may also mix and match as the options are not exclusive.
Attaching express handlers
When creating your mock server, a reference to the underlying raw express app is available. You can attach any response handlers you want:
const stubbornServer = ;const stub = ; // Attaching express handlers directly via `app` raw reference.stubapp; stubstart;// from this point, you may run your queriesstub;
Including express handlers
Instead of manually attaching handlers to the app, you may specify paths to
express handlers. The handlers will then be require()
ed for you.
This example is functionally equivalent to the example above:
main.js
:
const stubbornServer = ;const stub = ; stubconfig; stubstart;// from this point, you may run your queriesstub;
handler.js
:
module { app;};
Configuration-driven
By default, when the server recieves a request it will look into the directory
specified by the pathToMocks
configuration option for a mock response.
The file name serving as a mock must match the request path plus the request method.
For example, a POST
request to http://localhost:3000/api/service
will try
to find files at the following locations:
/path/to/mocks/api/service/post.js
/path/to/mocks/api/service/post.json
/path/to/mocks/api/service/post/index.js
/path/to/mocks/api/service/post/index.json
Basically, it's a require.resolve
that finds the proper mock response files.
The following is an example of a basic configuration driven post.js
mock:
// this function is the handler being calledmodule { // req / res are from express console; // POST // stub is stubborn server object console; res;};
and a post.json
mock that returns the same mock response data:
"hello": "world"
Plugins
A plugin architecture allows you to extend even more the custom functionality of your server.
Custom loaders
Add your own custom loader that takes precedence over the default behavior of file system lookup and the fallbacks
property - this way even if your loader throws you can still rely on the standard functionality.
Here is an example of a custom loader that uses sent data in order to load a mock:
const stubbornServer = ;const stub = ; stubstart plugins: { return ;
NOTE: you may also define multiple loaders, allowing you to have multiple custom fallbacks systems.
License
GPL-3.0 © 2018 Olivier Rousseau-Guyot