Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coverage generated as 0% and paramters is 'null' in a case if parameter is a reference to component parameters block #83

Open
1 task
adzest opened this issue May 11, 2021 · 3 comments
Labels
type:bug Something isn't working

Comments

@adzest
Copy link

adzest commented May 11, 2021

I'm submitting a ...

  • bug report

What is the current behavior?

Coverage report score 0% and a parameter is 'null' If the openapi3 spec contains parameter as ref to component/parameters block:
`paths:
/pets:
get:
summary: List all pets
operationId: listPets
tags:
- pets
parameters:
- $ref: '#/components/parameters/pets_limit'

...

components:
parameters:
pets_limit:
name: limit
in: query
description: How many items to return at one time (max 100)
required: false
schema:
type: integer
format: int32
example: 1`

If the current behavior is a bug, please provide steps to reproduce, broken swagger specification, and swagger-coverage-output:

  • openapi3 spec:
    `openapi: "3.0.0"
    info:
    version: 1.0.0
    title: Swagger Petstore
    license:
    name: MIT
    servers:
    • url: http://petstore.swagger.io/v1
      paths:
      /pets:
      get:
      summary: List all pets
      operationId: listPets
      tags:
      - pets
      parameters:
      - $ref: '#/components/parameters/pets_limit'
      responses:
      '200':
      description: A paged array of pets
      headers:
      x-next:
      description: A link to the next page of responses
      schema:
      type: string
      content:
      application/json:
      schema:
      $ref: "#/components/schemas/Pets"
      default:
      description: unexpected error
      content:
      application/json:
      schema:
      $ref: "#/components/schemas/Error"
      post:
      summary: Create a pet
      operationId: createPets
      tags:
      - pets
      responses:
      '201':
      description: Null response
      default:
      description: unexpected error
      content:
      application/json:
      schema:
      $ref: "#/components/schemas/Error"
      /pets/{petId}:
      get:
      summary: Info for a specific pet
      operationId: showPetById
      tags:
      - pets
      parameters:
      - name: petId
      in: path
      required: true
      description: The id of the pet to retrieve
      schema:
      type: string
      responses:
      '200':
      description: Expected response to a valid request
      content:
      application/json:
      schema:
      $ref: "#/components/schemas/Pet"
      default:
      description: unexpected error
      content:
      application/json:
      schema:
      $ref: "#/components/schemas/Error"
      components:
      parameters:
      pets_limit:
      name: limit
      in: query
      description: How many items to return at one time (max 100)
      required: false
      schema:
      type: integer
      format: int32
      example: 1
      schemas:
      Pet:
      type: object
      required:
      - id
      - name
      properties:
      id:
      type: integer
      format: int64
      name:
      type: string
      tag:
      type: string
      Pets:
      type: array
      items:
      $ref: "#/components/schemas/Pet"
      Error:
      type: object
      required:
      - code
      - message
      properties:
      code:
      type: integer
      format: int32
      message:
      type: string`
  • use maven dep:
    <dependency> <groupId>com.github.viclovsky</groupId> <artifactId>swagger-coverage-rest-assured</artifactId> <version>1.4.1</version> </dependency>
  • run GetPets.shouldSee200 test
  • coverage output contains 'limit' field
  • serve the report with
    ./1.4.1/bin/swagger-coverage-commandline

What is the expected behavior?

Coverage has a 'limit' parameter.

What is the motivation/use case for changing the behavior?

Expected behavior for base open spec functionality.

Other information

tag_name: 1.4.1

@viclovsky viclovsky added the type:bug Something isn't working label May 11, 2021
@kk2491
Copy link

kk2491 commented Jan 14, 2022

@adzest Were you able to find a work around for this bug?

Thank you

@ruiTLF
Copy link

ruiTLF commented May 18, 2023

@viclovsky I'm also facing this issue . Will this be fixed ?
Thanks !

@adzest
Copy link
Author

adzest commented Jun 8, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants