Customizing SDK Tests

Disable auto generation of tests for specific operations

When generateNewTests is enabled in the .speakeasy/gen.yaml file, all new operations found on the next generation after they are added will automatically have workflows created for then in the .speakeasy/tests.arazzo.yaml file and therefore tests will be generated for them.

To disable auto generation of tests for specific operations, the x-speakeasy-test extension can be added to the operation in the OpenAPI document.

openapi: 3.1.0
# ...
paths:
  /example1:
    get:
      x-speakeasy-test: false # Disables auto generation of tests for this operation
      # ...
# ...

alternatively if a workflow/test already exists that references the operation in the .speakeasy/tests.arazzo.yaml file, then no new workflow will be created for the operation.

Grouping tests

By default, all tests will be generated into a single file related to the main SDK class for example sdk.test.ts or test_sdk.py. This can be configured by adding a x-speakeasy-test-group extension to the workflow which will determine which tests will be grouped together in seperate test files.

arazzo: 1.0.0
# ...
workflows:
  - workflowId: some-test
    x-speakeasy-test-group: user # All tests in the user group will end up in the `user.test.ts`/`test_user.py`/`user_test.go` files
    # ...

Generate tests only for specific targets

By default, all tests will be generated for all supported targets. But using the x-speakeasy-test-targets extension, it is possible to generate tests only for specific targets. This may be useful if tests are either not needed for certain languages or they may be failing in a certain language.

arazzo: 1.0.0
# ...
workflows:
  - workflowId: some-test
    x-speakeasy-test-targets: # Only generate tests for the typescript target
      - typescript
    # ...

Data Handling

The definition of each operation will determine what data is used in generated testing. In addition to the data type system shaping data, OpenAPI Specification supports examples. Test generation will automatically use defined examples when available. In the absense of defined examples, the test generation will attempt to use a realistic example based on the type, format (if set), and property name (if applicable).

Example Property

By default, a single test will be created based on any example properties found throughout any defined operation parameters, requestBody, and responses.

In this example, a single test is created for the updatePet operation with id, name, and photoUrls data:

This test is created for the updatePet operation.

The operation uses the Pet shared component for both the request body and response.

The Pet shared component is an object type with required name and photoUrls properties.

While not required, the Pet object id property has an example property, which will be automatically included in the test.

The required Pet object name property has an example property, which will be included in the test.

The required Pet object photoUrls property does not include an example property, however it will have an example value automatically created since it is required.

openapi.yaml

paths:
  "/pet":
    put:
      tags:
      - pet
      summary: Update an existing pet
      description: Update an existing pet by Id
      operationId: updatePet
      requestBody:
        description: Update an existent pet in the store
        content:
          application/json:
            schema:
              "$ref": "#/components/schemas/Pet"
        required: true
      responses:
        '200':
          description: Successful operation
          content:
            application/json:
              schema:
                "$ref": "#/components/schemas/Pet"
components:
  schemas:
    Pet:
      required:
      - name
      - photoUrls
      type: object
      properties:
        id:
          type: integer
          format: int64
          example: 10
        name:
          type: string
          example: doggie
        category:
          "$ref": "#/components/schemas/Category"
        photoUrls:
          type: array
          items:
            type: string
        tags:
          type: array
          items:
            "$ref": "#/components/schemas/Tag"
        status:
          type: string
          description: pet status in the store
          enum:
          - available
          - pending
          - sold

This definition creates a test with Pet object request body and response data:

id: 10
name: doggie
photoUrls:
  - <value>

Examples Property

Define multiple tests for an operation using the examples property, which in this context is a mapping of example name string keys to example values. Prevent missing or mismatched test generation by ensuring the same example name key is used across all necessary parameters, requestBody, and responses parts of the operation. If desired, define reusable examples under components similar to schemas.

In this example, multiple tests (fido and rover) are created for the addPet operation:

These tests are created for the addPet operation.

This operation includes both request body and response examples.

An addPet operation fido test is created with example request body and response data.

An addPet operation rover test is created with example request body and response data.

openapi.yaml

paths:
  "/pet":
    post:
      tags:
      - pet
      summary: Add a new pet to the store
      description: Add a new pet to the store
      operationId: addPet
      requestBody:
        description: Create a new pet in the store
        content:
          application/json:
            schema:
              "$ref": "#/components/schemas/Pet"
            examples:
              fido:
                summary: fido request
                description: fido example requestBody for test generation
                value:
                  name: Fido
                  photoUrls:
                    - https://www.example.com/fido.jpg
                  status: available
              rover:
                summary: rover request
                description: rover example requestBody for test generation
                value:
                  name: Rover
                  photoUrls:
                    - https://www.example.com/rover1.jpg
                    - https://www.example.com/rover2.jpg
                  status: pending
        required: true
      responses:
        '200':
          description: Successful operation
          content:
            application/json:
              schema:
                "$ref": "#/components/schemas/Pet"
              examples:
                fido:
                  summary: fido response
                  description: fido example response for test generation
                  value:
                    id: 1
                    name: Fido
                    photoUrls:
                      - https://www.example.com/fido.jpg
                    status: available
                rover:
                  summary: rover response
                  description: rover example response for test generation
                  value:
                    id: 2
                    name: Rover
                    photoUrls:
                      - https://www.example.com/rover1.jpg
                      - https://www.example.com/rover2.jpg
                    status: pending

Ignoring Data

Data properties can be explicitly ignored in testing via the x-speakeasy-test-ignore annotation.

In this example, the other property will be omitted from test generation:

paths:
  /example:
    get:
      # ... other operation configuration ...
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  data:
                    type: string
                  other:
                    type: string
                    x-speakeasy-test-ignore: true

Next Steps

Setup testing in GitHub Actions