A library to bridge Swagger API specifications and the Mountebank Test-Double tool
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
config
demo
src
test
.gitignore
.travis.yml
KnownIssues.md
README.md
_config.yml
package.json
swaggerbanklogo.png

README.md

Build Status Coverage Status alt text

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.

Install

npm install swaggerbank

Usage

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/SwaggerBank.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!

Mocked Property Generation

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.

Random

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

Static

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

Example

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

Incomplete Features / Bugs / TODOS

See Known Issues