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

feat: Introduce more flexibility in the stub request conditions #246

Closed
dukeofharen opened this issue May 28, 2022 · 0 comments
Closed

feat: Introduce more flexibility in the stub request conditions #246

dukeofharen opened this issue May 28, 2022 · 0 comments
Labels
enhancement Enhancement of the code, not introducing new features.

Comments

@dukeofharen
Copy link
Owner

dukeofharen commented May 28, 2022

Feature Request

Describe the Feature Request

Right now, you can define a stub like this:

id: situation-01
tenant: 01-get
conditions:
  method: GET
  url:
    path: /users
    query:
      id: 12
      filter: first_name
response:
  statusCode: 200
  text: |
    {
      "first_name": "John"
    }
  headers:
    Content-Type: application/json

The request conditions under path and query are checked as regex / substring pattern. So in the above example, the path condition succeeds if the request path is for example both "/users" or "/users/1"; it doesn't matter. This is very flexible, but may put new users a bit off track, as they might expect that the path should always be exactly "/users". You can of course update the path condition to be a regular expression that checks for the exact value "/users", but regex is not always the most user friendly option.

Describe Preferred Solution

A solution would be an extra set of "keywords" that can be used in the stub conditions so you can specify how the string should be checked. Above example might be rewritten in the following form:

id: situation-01
tenant: 01-get
conditions:
  method: GET
  url:
    path:
      equals: /users
    query:
      id:
        equals: 12
      filter:
        equals: first_name
response:
  statusCode: 200
  text: |
    {
      "first_name": "John"
    }
  headers:
    Content-Type: application/json

You can see that path and the values under query no longer have a string value, but an object with a key equals. In this situation, HttPlaceholder will check if the values exactly equal the values in the stub. This means if the path is "/users/1", the stub will fail. By default, the string will be checked "case sensitive", so "/Users" will fail as well.

The following keywords will be supported:

  • equals: case sensitive check on exact string
  • notequals: same as equals, but succeeds if string is NOT equal to the given value
  • contains: case sensitive check on part of string
  • notcontains: same as contains, but succeeds if string is NOT part of the given value
  • startswith: case sensitive check to check if string starts with this value
  • doesnotstartwith: same as startswith, but checks that string does NOT start with this value
  • endswith: case sensitive check to check if string ends with this value
  • doesnotendwith: same as endswith, but checks that string does NOT end with this value
  • *ci: postfix that is ONLY applicable to keywords above. Makes it so that the check will be performed "case insensitive". Example: notequalsci.
  • regex: checks string on a given regular expression (essentially does the same as providing the value as plain string to the request condition)
  • regexnomatches: same as regex, but checks that regex has 0 matches.
  • present: checks whether a given value is present. Handy for example when you want to check if a query parameter or JSON variable was sent, but you do not have to check the value.
  • notpresent checks whether a given value is NOT present.

Request condition checkers that need to be updated:

  • BodyConditionChecker
  • FormValueConditionChecker
  • FullPathConditionChecker
  • HeaderConditionChecker
  • HostConditionChecker
  • IsHttpsConditionChecker
  • JsonPathConditionChecker
  • PathConditionChecker
  • QueryStringConditionChecker
  • ScenarioStateConditionChecker
  • XPathConditionChecker

JsonConditionChecker can not be updated based on how it works.

Describe Alternatives

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR?
Yes / No (Help can be provided if you need assistance submitting a PR)

@dukeofharen dukeofharen added the enhancement Enhancement of the code, not introducing new features. label May 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement of the code, not introducing new features.
Projects
None yet
Development

No branches or pull requests

1 participant