Skip to content

Latest commit

 

History

History
14 lines (10 loc) · 2.18 KB

testing-mock-servers.md

File metadata and controls

14 lines (10 loc) · 2.18 KB

Testing Mock Servers

Mock servers provide an opportunity to provide specific business use cases that need testing, providing a specific set of APIs that mimic what is in production, but are available with data and workflows that represent real-world processes, helping simulate some aspects of what is available in production.

Elements

These are the elements of mock servers for use for testing.

  • Names -
  • Collections - A machine-readable artifact that acts as a container for storing and organizing multiple API requests, providing an executable, self-documented reference for a complete API, a subset of an API, as well as workflows containing multiple requests from across many different APIs in a specific order, with a precise business function.
  • Environments - Machine-readable environments for APIs allow for abstracting away common elements of an API environment from the definition of each API, allowing different environments to be paired with OpenAPI and collections for each API at design, development, and build time.
  • Public - Designating a workspace, APIs, collections, environments, and monitors having a public visibility that makes them discoverable via the public API network and search engines, increasing the audience for an API by making it available publicly, while still limiting who can actually edit artifacts and change configuration, limiting engagement with public consumers to watches, forks, and commenting on APIs and collections.
  • Keys - API keys provide the simplest form of access to an API, allowing consumers to sign up for an account, define what their application is, and then receive a key they can include in headers or other parameters to identify themselves, ensuring that API producers are fully aware of everyone who has access to an API, and all consumers have a way to clearly identify themselves and receive personalized usage data for each key.
  • Usage - Once an API is implemented into production code, a developer decides whether to deepen adoption of your API. They might increase traffic or accommodate other user scenarios. This is when developers take a hard look at latency, responsiveness, flexibility, and scalability.