A library to bridge Swagger API specifications and the Mountebank Response Stubbing Tool (via interface provided by Mountebank-Helper). Pass in your API's Swagger spec file and get a full-blown mocked out version of your API to test against.
npm install swaggerbank
const SwaggerBank = require('swaggerbank');
const api = new SwaggerBank.API('./demoApi.yaml');
api.validateAPI()
.then( () => {
api.setupMountebankImposter(3000);
})
To see this in action right now:
git clone https://github.com/Tzinov15/swagger-bank.git
cd SwaggerBank
npm install
node demo/full.demo.js # from the root of the project.
Now navigate to localhost:3000/v1/areas
to see a mocked route in action! This mocked API is
based on the demoApi.yaml
Swagger Spec. Explore the spec and play around with the mocked responses. Whenever you're ready, swap in your own spec!
SwaggerBank allows you to set how you want your mocked API to behave. You have three choices (configurable through setting PROP_GEN
) Try these out with the node demo/full.demo.js
example above.
PROP_GEN=random: randomly generated data (that adheres to the defined schema) will be used as the mocked response. For example, if you have a property with type: string
and format: uuid
, then a random valid uuid will be generated for that property when it gets returned as part of a mocked response. To set custom format types for strings and ints, add them to config/options.js
PROP_GEN=static: static data pulled from config/options.js
(that adheres to the defined schema) will be used as the mocked response. See repo for how config/options.js
should be configured
PROP_GEN=example: The example specified in your spec under that response will be directly used as the mocked response. Important For this feature to work, ALL of your routes must have an example section
Another feature that is coming soon is the ability to hardcode a particular value for a given property name. Ex: If in your spec there is a property called remoteIp
that appears in several responses which you know will always have the same value whenever the real server gets hit, then you can set the hardcoded value for this property. This will allow for setting up a mocked API that more closely reflects what the real API will do
See Known Issues