swagger-police is a command line tool for validating backend APIs against the published swagger specification. It can be plugged into a continuous integration system to ensure that the backend APIs confirms to the behaviour mentioned in the published swagger specification.

This library is very similar to and inspired from abao (https://github.com/cybertk/abao) which does similar validations for a RAML spec

Please Note: The library is still in development !

Features

• Calls every API defined in the swagger file by generating mock data from the specs (data can be customised, see usage). This ensures that the url params, query params, headers and the body defined in the spec is supported by the service.
• Verifies the HTTP response status against the specs.
• Verifies the response body against the schema defined in specs (JSON schema validation).
• Supports the following hook methods for customising the tests (see Hooks)
  • BeforeAll
  • AfterAll
  • BeforeEach
  • AfterEach
  • Test specific Before and After

Limitations

• Response headers are not validated against the schema
• Only JSON and form posts are supported in request body
• Only JSON responses will be validated against a schema

Installation

npm install -g swagger-police

Usage

$ swagger-police

  Usage: swagger-police <swagger URL/path> [options]

  Options:

    -h, --help                        output usage information
    --server [server]                 The API endpoint
    --hook-files [hookFiles]          Specify pattern to match hook files
    --testcase-names [testcaseNames]  Print all the testcase names (does not execute the tests)

• Swagger URL/path - The path or the URL to the swagger file
• Server - The API endpoint base url. No need to specify this if a swagger url is specified and the APIs are hosted in the same server.
• Hook Files - A glob pattern (reletive to the execution directory) to load the hook files.

Mock Data

The mock data for the requests are generated using the swagmock package. But it can be customised by either of the following ways

• The request data can be customised in the testcase specific before hook by modifying the testcase.request object. See Testcase Object Format for the parameter names and values.
• Swagger does not provide a way to specify examples in request parameters yet, but allows vendor specific extensions. The tool will look for x-example property in the parameter and will use that instead.

"post": {
    "description": "Creates a new pet in the store.  Duplicates are allowed",
    "operationId": "addPet",
    "produces": [
        "application/json"
    ],
    "parameters": [
        {
            "name": "pet",
            "in": "body",
            "description": "Pet to add to the store",
            "required": true,
            "schema": {
                "$ref": "#/definitions/newPet"
            },
            "x-example": {
                "id": 0,
                "category": {
                    "id": 0,
                    "name": "dog"
                },
                "name": "doggie",
                "photoUrls": [
                    "http://doggie.com/avatar"
                ],
                "tags": [
                    {
                        "id": 0,
                        "name": "string"
                    }
                ],
                "status": "available"
            }
        }
    ],
    "responses": {
        "200": {...

Hooks

The tool supports the following test hooks to enable setup/tear-down tasks or customising the individual tests. Hooks are simple JavaScript files which have access to a global hooks object with methods to add the specific hooks.

BeforeAll and AfterAll

These will be executed once before the tests start and after all the tests have been executed. Note that only one of each type can be specified, there cannot be more than one beforeAll/afterAll hooks. However, testcase specific hooks can be specified, see below.

hooks.beforeAll((testcases, done) => {
    done();
});

hooks.afterAll((testcases, done) => {
    done();
});

• testcases - An array of testcase objects to be executed. This is generated from the swagger specs. Any changes made to the testcase objects in the beforeAll hook will be reflected in the tests.
• done - The callback function

BeforeEach and AfterEach

These will be executed before and after every test. Note that only one of each type can be specified, there cannot be more than one beforeEach/afterEach hooks. However, testcase specific before/after hooks can be specified, see below.

hooks.beforeEach((testcase, done) => {
    done();
});

hooks.afterEach((testcase, done) => {
    done();
});

• testcase - The specific testcase this hook is being executed for. Any changes made to the testcase objects in the beforeEach hook will be reflected in the tests.
• done - The callback function

Testcase specific hooks

before and after testcase specific hooks can be specified which will only be executed before and after the specific testcase. The testcases are identified using a generated name. Run the tool with the --testcase-names option to print out all the testcase names.

The hooks can be specified using the following method

hooks.add('GET /pet/{petId} -> 200', {
    before: (testcase, done) => {
        done();
    },
    
    after: (testcase, done) => {
        done();
    }
});

• 1st Argument - The testcase name. Please note that this is case sensitive.
• 2nd argument - An object with before and after functions which takes in testcase (The testcase object representing the specific test) and a callback. Any changes made to the testcase object will reflect in the test.

If more than one such hook is specified for a specific test, the test will be executed once for every hook specified. Custom test name can be added to identify each pass. See below

hooks.add('GET /pet/{petId} -> 200 # Pass 1', {
    before: (testCase, done) => {
        done();
    },
    
    after: (testCase, done) => {
        done();
    }
});

hooks.add('GET /pet/{petId} -> 200 # Pass 2', {
    before: (testCase, done) => {
        done();
    },

    after: (testCase, done) => {
        done();
    }
});

Testcase Object Format

Example

{
  "name": "GET /pets -> 200",
  "basePath": "/api",
  "request": {
    "path": "/pets/{id}",
    "method": "get",
    "pathParams": {
      "id": 4948307189170176
    },
    "query": {
      "tags": "EhuDzn",
      "limit": -4836393545105408
    },
    "headers": {
        "x-ample-header": "value"
    },
    "body": {}
  },
  "response": {
    "statusCode": 200,
    "schema": {
      "type": "array",
      "items": {
        "type": "object",
        "required": [
          "id",
          "name"
        ],
        "properties": {
          "id": {
            "type": "integer",
            "format": "int64"
          },
          "name": {
            "type": "string"
          },
          "tag": {
            "type": "string"
          }
        }
      }
    }
  }
}

• request - contains the data with which the API call will be made. Modify these values in before hook if the request needs to be customised
• response - contains the expected response data like the status code, schema & response headers