This PR have fix for two issues mentioned in the description

[ganeshnikam18]

1. For StringFieldLeftBoundary and StringFieldRightBoundary fuzzer, cats was not fuzzing the fields if minLength or maxLength is not specified for the field. As per the documentation it should fuzz such field with empty string (for leftBoundary) and with 10000 char string (for right boundary). https://endava.github.io/cats/docs/fuzzers/field-fuzzers/string-left-boundary https://endava.github.io/cats/docs/fuzzers/field-fuzzers/string-right-boundary

I have added this fix using the reference of IntegerFieldRightBoundary Fuzzer

2. I have tested below scenario:

• One api endpoint path is present in swagger.json spec file. Say /test/order, with POST method and required requestBody schema
• This API endpoint is not present/implemented on Server
• When we run the cats tool with this spec file and with HappyPathFuzzer, then cats tool reports warning like below:

  "scenario": "Send a 'happy' flow request with all fields and all headers",

"result": "warn", "resultReason": "Response content type not matching the contract", "id": "Test 1", "fuzzer": "HappyPath", "path": "/test1/order", "resultDetails": "Response content type not matching the contract: expected [application/json], actual [application/problem+json]", "timeToExecuteInSec": 0.202, "httpMethod": "post",

• The response code received for above test case is 404 Not found
• In this case we should reported ERROR instead of WARNING. Because expected response code was 2XX and we received 404
• So there is issue of precedence when we are doing reporting
  3. I have added the fix for this issue by changing the reporting precedence
  4. You can verify the fix and update it if required

[en-milie]

For (1) yes, it seems that documentation is not aligned with the implementation. Please also update the corresponding tests as they are failing.

For (2) I am a bit skeptical. Did you use the latest version of CATS to run that test? It shouldn't raise a warn as application/json and application/problem+json content types are equivalent. I agree that we should raise errors first. And it will probably be a better idea to increase the warn in this case to error.

So, in conclusion, please also updates the corresponding tests for (1).

And for (2) try running with latest CATS.

[ganeshnikam18]

For (1) I have updated the test cases and added the commit

For (2) I have verified with latest version as you suggested. It does not report the warn for content-type mis-match. You can improve the current sequence of check to report error 1st and then warning and then success case. I had added that commit as per my understanding. You can reject the commit

[en-milie]

Merged now, but preserving the existing logic to report results.