You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
The text was updated successfully, but these errors were encountered:
Feature Request
Describe the Feature Request
Right now, you can define a stub like this:
The request conditions under
path
andquery
are checked as regex / substring pattern. So in the above example, thepath
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:
You can see that
path
and the values underquery
no longer have a string value, but an object with a keyequals
. In this situation, HttPlaceholder will check if the values exactly equal the values in the stub. This means if thepath
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 stringnotequals
: same asequals
, but succeeds if string is NOT equal to the given valuecontains
: case sensitive check on part of stringnotcontains
: same ascontains
, but succeeds if string is NOT part of the given valuestartswith
: case sensitive check to check if string starts with this valuedoesnotstartwith
: same asstartswith
, but checks that string does NOT start with this valueendswith
: case sensitive check to check if string ends with this valuedoesnotendwith
: same asendswith
, 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 asregex
, 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:
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)
The text was updated successfully, but these errors were encountered: