All Projects → noahdietz → oatts

noahdietz / oatts

Licence: Apache-2.0 License
DEPRECATED in favor of https://github.com/google/oatts

Programming Languages

javascript
184084 projects - #8 most used programming language
Handlebars
879 projects

Projects that are alternatives of or similar to oatts

Swurg
Parse OpenAPI documents into Burp Suite for automating OpenAPI-based APIs security assessments (approved by PortSwigger for inclusion in their official BApp Store).
Stars: ✭ 94 (+261.54%)
Mutual labels:  openapi, openapi-specification
Openapi Diff
Utility for comparing two OpenAPI specifications.
Stars: ✭ 208 (+700%)
Mutual labels:  openapi, openapi-specification
Swagger meqa
Auto generate and run tests using swagger/OpenAPI spec, no coding needed
Stars: ✭ 151 (+480.77%)
Mutual labels:  openapi, testing-framework
Connect Api Specification
This repository contains the OpenAPI specification as well as templates for generating SDKs for Square's APIs
Stars: ✭ 56 (+115.38%)
Mutual labels:  openapi, openapi-specification
oas
OpenAPI Spec builder in go
Stars: ✭ 15 (-42.31%)
Mutual labels:  openapi, openapi-specification
Springdoc Openapi
Library for OpenAPI 3 with spring-boot
Stars: ✭ 1,113 (+4180.77%)
Mutual labels:  openapi, openapi-specification
Redoc
📘 OpenAPI/Swagger-generated API Reference Documentation
Stars: ✭ 15,935 (+61188.46%)
Mutual labels:  openapi, openapi-specification
Oas Kit
Convert Swagger 2.0 definitions to OpenAPI 3.0 and resolve/validate/lint
Stars: ✭ 516 (+1884.62%)
Mutual labels:  openapi, openapi-specification
openapi
OpenAPI 3 Specification for golang
Stars: ✭ 18 (-30.77%)
Mutual labels:  openapi, openapi-specification
openapi4j
OpenAPI 3 parser, JSON schema and request validator.
Stars: ✭ 92 (+253.85%)
Mutual labels:  openapi, openapi-specification
Spectral
A flexible JSON/YAML linter for creating automated style guides, with baked in support for OpenAPI v2 & v3.
Stars: ✭ 876 (+3269.23%)
Mutual labels:  openapi, openapi-specification
Unchase.OpenAPI.Connectedservice
📜 Visual Studio extension to generate OpenAPI (Swagger) web service reference.
Stars: ✭ 69 (+165.38%)
Mutual labels:  openapi, scaffolding
Swagger Core
Examples and server integrations for generating the Swagger API Specification, which enables easy access to your REST API
Stars: ✭ 6,898 (+26430.77%)
Mutual labels:  openapi, openapi-specification
Openapivalidators
Use Jest or Chai to assert that HTTP responses satisfy an OpenAPI spec
Stars: ✭ 77 (+196.15%)
Mutual labels:  openapi, openapi-specification
Apispec
A pluggable API specification generator. Currently supports the OpenAPI Specification (f.k.a. the Swagger specification)..
Stars: ✭ 831 (+3096.15%)
Mutual labels:  openapi, openapi-specification
Drf Yasg
Automated generation of real Swagger/OpenAPI 2.0 schemas from Django REST Framework code.
Stars: ✭ 2,523 (+9603.85%)
Mutual labels:  openapi, openapi-specification
Openapi Specification
The OpenAPI Specification Repository
Stars: ✭ 22,603 (+86834.62%)
Mutual labels:  openapi, openapi-specification
Swagger Parser
Swagger Spec to Java POJOs
Stars: ✭ 468 (+1700%)
Mutual labels:  openapi, openapi-specification
Flasgger
Easy OpenAPI specs and Swagger UI for your Flask API
Stars: ✭ 2,825 (+10765.38%)
Mutual labels:  openapi, openapi-specification
OpenAlchemy
Define SQLAlchemy models using the OpenAPI specification.
Stars: ✭ 39 (+50%)
Mutual labels:  openapi, openapi-specification

Build Status

THIS REPOSOITORY IS DEPRECATED. This project's development has been moved to https://github.com/google/oatts. All new NPM releases will be coming from that repository.

OpenAPI Test Templates (oatts)

Generate basic unit test scaffolding for your OpenAPI specification.

Disclaimer

This is not an officially supported Google product.

oatts is based off of the swagger-test-templates module and the lessons learned during its development.

This is a work in progress.

Goal

The goal of oatts is to provide a standalone module for generating Node.js unit test code scaffolding based on a given OpenAPI specification.

The hope is that by providing such a tool, API developers will be encouraged to test the contract between their spec and backend early, often and continuously as the project grows.

Usage

There are a couple ways to use oatts.

Module

Install via npm

npm install --save oatts

Then use it in code

var oatts = require('oatts');

var options = {
    // see "Options" section below for available options
};

var tests = oatts.generate('/path/to/openapi.yaml', options);

console.log(tests)

Command line interface

Install globally via npm

npm install -g oatts

Then use in your command line

> oatts generate --help

  Usage: generate [options]

  generate unit test scaffolding for a given OpenAPI/Swagger Spec

  Options:

    -h, --help                             output usage information
    --host <host>                          target hostname to use in test generation
    -p, --paths <paths>                    comma separated list of paths to generate tests for
    -e, --samples                          generate sample response bodies rather than schema, if applicable
    -s, --spec <spec>                      path to the target OpenAPI/Swagger spec document to consume
    -w, --writeTo <writeTo>                directory to write the generated tests to file
    -c, --consumes <consumes>              consumes/content-type to use in request when applicable to the API resource
    -o, --produces <produces>              produces/accept to use in request when applicable to the API resource
    -u, --customValues <customValues>      custom request values to be used in generation; takes precedent over a customValuesFile
    --customValuesFile <customValuesFile>  path to JSON file with custom request values to be used in generation
    -m, --scheme <scheme>                  which scheme to use if multiple are present in spec
    -t --templates <templateDir>           path to direcotry of custom templates
    -S, --status-codes <statusCodes>       comma separated list of status codes to explicity generate tests for

> oatts generate -s ./path/to/openapi.yaml -w ./output/dir
> ls ./output/dir
pet-test.js  pet-{petId}-uploadImage-test.js  user-test.js 
. . .

Using the result

The resulting test files are built using the mocha testing framework and chakram API testing framework. Thus, you will need both of these dependencies installed in order to run your newly generated tests.

After installing these, you can run the tests with mocha:

# start your API server to test against!!
> mocha --recursive <test directory>


    tests for /goodbye
        tests for get
            ✓ should respond 200 for "Success" (57ms)

    tests for /hello
        tests for get
            ✓ should respond 200 for "Success"


    2 passing (82ms)

Custom Values

Custom values can be supplied through both the command line and a JSON file. The in-line, command line supplied JSON will take precedent.

An example custom values JSON file can be found here.

Custom Templates

Custom templates can be supplied via the templates option. The directory pointed to by the option must contain 4 Handlebars templates named the same way as those found in ./templates.

  • topLevel.handlebars: the top level template for a single test file
  • pathLevel.handlebars: the path level template, usually the beginning of a test suite for a specific path
  • operationLevel.handlebars: the operation level template, for a single operation test suite
  • transactionLevel.handlebars: the template for a single transaction, or a single response code's unit test

The data available to be used in the templates is specified in the ProcessedSpec type.

There are also a few helpers available to be used in the Handlebars templates, which can be found in the templateHelpers documentation namespace. Use the default templates as examples of how to use them.

Options

The following options can be passed to the generation function, some/all are exposed in the accompanying CLI:

Name CLI Flag Default Required Description
spec --spec -s n/a true Path to a swagger.yaml or openapi.yaml
host --host spec.host false Hostname to put in test requests; defaults to host in given spec
paths --paths -p spec.paths false API paths to generate tests for; defaults to all paths in given spec
samples --samples -e false false Toggle generating sample responses for assertion
writeTo --writeTo -w n/a false Directory to write generated tests to; will create the directory if it doesn't exist
consumes --consumes -c operation.consumes[0] | | spec.conumes[0] false Consumes header to use in a request when applicable
produces --produces -o operation.produces[0] | | spec.produces[0] false Produces header to use in a request when applicable
customValues --customValues -u n/a false Values to be populated in requests where specified; overrides customValuesFile
customValuesFile --customValuesFile n/a false Path to a JSON file with values to populate in requests
scheme --scheme -m spec.schemes[0] false Override for multiple scheme present in a spec
templates --templates -t './templates' false Path to directory containing custom templates
statusCodes --status-codes -S operation.responses false comma separated list of status codes to explicity generate tests for
jsonRefs n/a false (See JsonRefs~JsonRefsOptions)
customFormats n/a false The key/value pair of custom formats (The keys are the format name and the values are async functions. See ZSchema Custom Formats)
customFormatGenerators n/a false The key/value pair of custom format generators (The keys are the format name and the values are functions. See json-schema-mocker Custom Format)
customValidators n/a false The custom validators. See DocumentValidationFunction

Testing

To test this module simply use the npm script

npm test

Discussion

If you have a question or a topic you'd like to discuss, please feel free to open a discussion on our Google Group oatts-users.

Contributing

Contributors are welcome! Please see CONTRIBUTING.md.

Copyright

Copyright 2018, Google Inc.

License

See LICENSE file.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].