npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@chezearth/swagger-test-templates

v1.4.4

Published

Generate test code from a Swagger spec. Updated by C Rethman to include newer dependencies that remove reported vulnerabilities

Downloads

89

Readme

Swagger Test Templates

| Linux | Windows | | ----- | ------- | | Build Status | Build Status |

Generate test code from a Swagger spec(version 2.0)

Usage

Install via npm

npm install --save swagger-test-templates

Use your Swagger API spec file to generate test for your API.

var stt = require('swagger-test-templates');
var swagger = require('/path/to/swagger.json');
var config = {
  assertionFormat: 'should',
  testModule: 'supertest',
  pathName: ['/user', '/user/{id}'],
  loadTest: [{pathName:'/user', operation:'get', load:{requests: 1000, concurrent: 100}}, { /* ... */ }],
  maxLen: 80,
  pathParams: {
    "id": "0123"
  }
};

// Generates an array of objects containing the test file content, following specified configuration
// the array contains objects with the scheme { name: <test-file-name>, test: <test-file-content> }
// tests = [ {name: base-path-test.js, test: ... }, {name: users-test.js, test: ... }]
var tests = stt.testGen(swagger, config);

API

swagger-test-templates module exports a function with following arguments and return values:

Arguments

  • assertionFormat required: One of should, expect or assert. Choose which assertion method should be used in output test code.
  • testModule required: One of supertest or request. Choose between direct API calls (request) vs. programatic access to your API (supertest).
  • pathName required: List of path names available in your Swagger API spec used to generate tests for. Empty array leads to all paths.
  • statusCodes optional Array with status codes to generate tests for. Useful for generating only happy-flow tests. Excluding this param will generate tests for all responses. A test is generated for the status code only when the status code is listed in the Swagger API spec.
  • loadTest optional: List of objects info in your Swagger API spec used to generate stress tests. If specify, pathName & operation are required. Optional fields requests defaults to 1000, concurrent defaults to 100.
  • maxLen optional: Maximum line length. If set to -1, descriptions will not be truncated. Defaults to 80.
  • pathParams optional: Object containing the values of a specific path parameters.
  • templatesPath optional String indicating a custom handlebars-template path for generating the tests. Note: copy all the templates to your custom directory, this is a 'all-or-nothing' path
  • requestData optional Object containing data to send with the request See section on requestData for more details

Return value

An array in which each string is content of a test file and the file name. Use this information to write those files to disk.

Sending requestData

Based on your schema there are a few modules out there that allow you to generate mock request payloads. You can send this mock data along with the tests generated by this module by filling the requestData property of the module. The mock data needs to have the following structure:

Mock HTTP request body

{
   '/endpoint': {
       operation: {
           'responseCode': [{ body: {}, description:'some description of the data'}]
       }
   }
 }

Mock Path Parameters

{
   '/pet/{name}': {
       get: {
           '200': [{ name: 'spot', description:'some description of the data'}]
       }
   }
 }

Mock Query Parameters

This will make a request to /pet?name=spot assuming that your swagger API has a definition for a name query parameter.

{
   '/pet': {
       get: {
           '200': [{ name: 'spot', description:'some description of the data'}]
       }
   }
 }

Mock HTTP Headers

This will add an HTTP header X-Token set to waestrydtufj assuming that your swagger API has a definition for that header.

{
   '/pet': {
       get: {
           '200': [{ 'X-Token': 'waestrydtufj', description:'some description of the data'}]
       }
   }
 }

Multiple objects within a status code request data array are supported. So, for example this could be:

{
     '/pet': {
         post: {
             '200': [
               {
                 body: {
                  id: 1,
                  otherProperty: 'some property that is a string'
                 },
                 description: 'the description for this data'
               },
               {
                 body: {
                  id: 2,
                  otherProperty: 'another value of that property'
                 },
                 description: 'the description for another data'
               }
             ]
         },
         get: {
            '200': [
              {
                guid: 'some_string_to_place_in_path',
                anotherPathParam: 100,
                description: 'valid path or query parameters'
              },
              {
                guid: 'some_other_string_to_place_in_path',
                anotherPathParam: 200,
                description: 'another valid path or query parameters'
              }
          ]
         }
     }
 }

Note: for get-requests matching data will be transferred to the pathParams. So setting config.pathParams directly will have the same effect (see above).

Every mockData item in the responseCode array will be used to generate a test. The description will be added to the "it" function for reference.

Parameters explicitly marked as required: false in your Swagger API spec, will only be set if there is a matching value in requestData object. Required parameters and parameters without explicitly set required flag in Swagger API spec will be set to either a matching value in requestData object or 'DATA GOES HERE' string.

License

MIT