Endava / cats

CATS is a REST API Fuzzer and negative testing tool for OpenAPI endpoints. CATS automatically generates, runs and reports tests with minimum configuration and no coding effort. Tests are self-healing and do not require maintenance.
Apache License 2.0
1.18k stars 73 forks source link

Invalid happy path fuzzing for array of numbers #144

Open RafDevX opened 1 week ago

RafDevX commented 1 week ago

Describe the bug When specifying that a request body should be a JSON array of numbers, CATS's HappyPath fuzzer is using strings (e.g. DGZTERFXUNVTGLSACSDVVV) instead of numbers.

To Reproduce Steps to reproduce the behaviour:

  1. Using a contract with the snippet below (OpenAPI 3.1)
  2. Run cats --contract=... --server=... --fuzzers=Happy
  3. Observe that HappyPath's attempted request is something like
    [
    "DGZTERFXUNVTGLSACSDVVV",
    "DGZTERFXUNVTGLSACSDVVV"
    ]

Expected behaviour CATS should send an array of numbers, not an array of strings, if it expects a 2xx response

Environment: Output of cats info:

Key           | Value
------------- | --------------------
OS Name       | Linux
OS Version    | 6.6.46
OS Arch       | amd64
Binary Type   | uber-jar
Cats Version  | 12.1.0
Cats Build    | 2024-10-08T20:17:57Z
Term Width    | 231
Term Type     | xterm-256color
Shell         | /run/current-system/sw/bin/zsh

Contract snippet:

paths:
    /sum:
        post:
            operationId: sum
            summary: Sum multiple numbers
            requestBody:
                description: The list of numbers to sum
                content:
                    application/json:
                        schema:
                            type: array
                            items:
                                type: number
                        examples:
                            list-of-three:
                                value:
                                    nums: [23, 27, 2]

Additional context I have tried type: number as well as type: integer (with and without format: int32).

This may very well be my own fault, and if so I apologize in advance - this is my first time using CATS.

Thank you for all your work maintaining this tool! :grinning:

en-milie commented 1 week ago

Hi @RafDevX. I need to do some updates on how examples are being considered. But the generation should be find. I use the following OpenAPI spec (starting from your snippet):

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  description: A sample API that uses a petstore as an example to demonstrate features in the OpenAPI 3.0 specification
  termsOfService: http://swagger.io/terms/
  contact:
    name: Swagger API Team
    email: apiteam@swagger.io
    url: http://swagger.io
  license:
    name: Apache 2.0
    url: https://www.apache.org/licenses/LICENSE-2.0.html
servers:
  - url: http://petstore.swagger.io/api
paths:
  /sum:
    post:
      operationId: sum
      summary: Sum multiple numbers
      requestBody:
        description: The list of numbers to sum
        content:
          application/json:
            schema:
              type: array
              items:
                type: number
            examples:
              list-of-three:
                value:
                  nums: [ 23, 27, 2 ]
      responses:
        '200':
          description: The sum of the numbers
          content:
            application/json:
              schema:
                type: number
              examples:
                sum-of-three:
                  value: 52

And I get the following payload:

[
  8.586701801327482,
  8.586701801327482
]
RafDevX commented 6 days ago

Hi, you're right -- if I change the OpenAPI spec version to 3.0.0, then it does generate numbers as expected. I think the problem was using v3.1.

To be honest I'm not even sure if you officially support 3.1, I couldn't find that information in the documentation. If you don't, then please feel free to close this issue, as far as I can tell from a quick test it's working fine in 3.0, but maybe consider specifying that in the README.

I just (perhaps incorrectly) assumed v3.1 was supported because of this line: https://github.com/Endava/cats/blob/16d76559184f0aa6bf6449c717049d6822ff799a/src/main/java/com/endava/cats/util/OpenApiParseResult.java#L29

Thanks again for your help!

en-milie commented 6 days ago

It does support OpenAPI v3.1. There was an issue I've fixed last night. I'll push the fix later today.