API Guidelines
  • adidas API Guidelines
  • General Guidelines
    • Introduction
    • API First
    • Contract
    • Immutability
    • Robustness
    • Common Data Types
    • Version Control System
    • Minimal API Surface
    • Rules for Extending
    • JSON
    • Security
    • Tooling
  • REST API Guidelines
    • Introduction
    • Core REST Principles
      • OpenAPI Specification
      • API Design Platform
      • Design Maturity
      • Testing
    • Protocol
      • HTTP
      • TLS
      • Separate Concerns
      • Request Methods
      • Status Codes
    • Message
      • Message Formats
      • Content Negotiation
      • HAL
      • Problem Detail
      • Foreign Key Relations
    • Application
      • Corporate Data Model
      • Common Data Types
    • Execution
      • Pagination
      • Long Running Tasks
        • Polling
        • Callback
        • Files Upload
      • Batch Operations
      • Search Requests
      • Query Requests with Large Inputs
      • Choosing Fields and Embedded Resources
      • Localization
      • Rate Limiting
      • Caching
      • Testing Enviroments
    • Evolution
      • Naming Conventions
      • Reserved Identifiers
      • URI Structure
      • Changes and Versioning
      • Phasing out Old Versions
    • Guides
      • API Testing CI Environment
      • Complete API Development
    • API Clients
      • Loose Coupling
    • Further References
  • Asynchronous API Guidelines
    • Introduction
    • Core Asynchronous Principles
      • Event Driven Architectures
      • Messages
        • Commands
        • Queries
        • Events
          • Events as Notifications
          • Events to Replicate Data
      • Protocols
      • Coupling
      • Bounded Context
      • Stream Processing
      • Naming Conventions
      • Tooling
        • Editors
        • Command Line Interface (CLI)
        • Generators
    • Kafka Asynchronous Guidelines
      • Introduction
        • Why AsyncAPI?
      • AsyncAPI Version
      • Internal vs Public Specifications
      • Key/Value Format
      • Message Headers
      • Specification Granularity
      • Self-Contained Specifications
        • Meaningful Descriptions
      • Schema Data Evolution
        • Backward Compatibility
        • Forward Compatibility
        • Full Compatibility
      • Automatic Schema Registration
      • Contact Information
      • AsyncAPI ID
      • Servers
      • Channels
      • Schemas
      • Security Schemes
      • External Docs
Powered by GitBook
On this page
  • Environment Prerequisites
  • Testing an API
  • Test Run Prerequisites
  • Running the Test
  1. REST API Guidelines
  2. Guides

API Testing CI Environment

PreviousGuidesNextComplete API Development

Last updated 2 months ago

This guide describes steps necessary for testing an API described in a swagger file with the in a CI Environment (Jenkins, TeamCity).

Environment Prerequisites

The following must be available in the CI environment before testing:

  1. Node.js runtime MUST be available in the CI environment:

     $ node -v
     v14.15.5
  2. MUST be installed globally in the CI environment:

     $ npm install -g dredd --no-optional
     $ dredd --version
     dredd v14.0.0

Testing an API

Test Run Prerequisites

To test an API within the CI environment provisioned as mentioned in the environment prerequisites, you will need the following:

  1. A swagger.yaml file with the description of API being tested

    The OpenAPI Specifciation file should be fetched from . In the case of SwaggerHub API Design Platform, the file can be fetched manually or via their API. Refer to , for details how to use SwaggerHub API.

    Alternativelly this can also be a remote file e.g. SwaggerHub URL, if the API is public its OAS file and reachable from the testing host.

  2. The host (address) of the service being tested

      $ export API_HOST=http://deheremap7336.emea.adsint.biz:8004`

Running the Test

Run:

$ dredd swagger.yaml $API_HOST

The Dredd will perform the tests and exits usually if the tests have passed. You can check the test result as with any other Unix tools with:

$ echo $?

Everything else but 0 should break the build. The test results will be visible in the CLI (log)

See .

Dredd API Testing Framework
Dredd
API Design Platform
Integrating with the SwaggerHub API
Dredd Command-line Interface