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
For documentation on using these matchers, check the [WireMock documentation](https://wiremock.org/docs/request-matching/)
919
920
920
-
921
921
### Negative context exists match
922
922
923
923
```json
@@ -938,6 +938,120 @@ For documentation on using these matchers, check the [WireMock documentation](ht
938
938
}
939
939
```
940
940
941
+
### Logical matches
942
+
943
+
This extension supports logical matches. The following matchers are available:
944
+
945
+
- `and`
946
+
- `or`
947
+
- `not`
948
+
949
+
The matchers can be combined with `hasContext` and `hasNotContext` as well was themselves, so you can create a fully nested structure.
950
+
951
+
Example for `not`:
952
+
953
+
```json
954
+
{
955
+
"request": {
956
+
"urlPathPattern": "/test/[^\/]+",
957
+
"method": "GET",
958
+
"customMatcher": {
959
+
"name": "state-matcher",
960
+
"parameters": {
961
+
"not": {
962
+
"hasContext": "{{request.pathSegments.[1]}}"
963
+
}
964
+
}
965
+
}
966
+
},
967
+
"response": {
968
+
"status": 400
969
+
}
970
+
}
971
+
```
972
+
973
+
Example for `and`:
974
+
975
+
```json
976
+
{
977
+
"request": {
978
+
"urlPathPattern": "/test/[^\/]+",
979
+
"method": "GET",
980
+
"customMatcher": {
981
+
"name": "state-matcher",
982
+
"parameters": {
983
+
"and": [
984
+
{
985
+
"hasContext": "{{request.pathSegments.[1]}}"
986
+
},
987
+
{
988
+
"hasNotContext": "anotherContext"
989
+
}
990
+
]
991
+
}
992
+
}
993
+
},
994
+
"response": {
995
+
"status": 200
996
+
}
997
+
}
998
+
```
999
+
1000
+
Example for `or`:
1001
+
1002
+
```json
1003
+
{
1004
+
"request": {
1005
+
"urlPathPattern": "/test/[^\/]+",
1006
+
"method": "GET",
1007
+
"customMatcher": {
1008
+
"name": "state-matcher",
1009
+
"parameters": {
1010
+
"or": [
1011
+
{
1012
+
"hasContext": "{{request.pathSegments.[1]}}"
1013
+
},
1014
+
{
1015
+
"hasContext": "otherContext"
1016
+
}
1017
+
]
1018
+
}
1019
+
}
1020
+
},
1021
+
"response": {
1022
+
"status": 200
1023
+
}
1024
+
}
1025
+
```
1026
+
1027
+
Example for nesting:
1028
+
1029
+
```json
1030
+
{
1031
+
"request": {
1032
+
"urlPathPattern": "/test/[^\/]+",
1033
+
"method": "GET",
1034
+
"customMatcher": {
1035
+
"name": "state-matcher",
1036
+
"parameters": {
1037
+
"not": {
1038
+
"or": [
1039
+
{
1040
+
"hasContext": "eitherContext"
1041
+
},
1042
+
{
1043
+
"hasContext": "orContext"
1044
+
}
1045
+
]
1046
+
}
1047
+
}
1048
+
},
1049
+
"response": {
1050
+
"status": 400
1051
+
}
1052
+
}
1053
+
```
1054
+
941
1055
## Retrieve a state
942
1056
943
1057
A state can be retrieved using a handlebar helper. In the example above, the `StateHelper` is registered by the name `state`.
@@ -1016,13 +1130,50 @@ Example with bodyFileName:
1016
1130
1017
1131
```json
1018
1132
[
1019
-
{{# each (state context='list' property='list' default='[]') }}
1020
1133
{
1021
-
"id": {{id}},
1022
-
"firstName": "{{firstName}}",
1023
-
"lastName": "{{lastName}}"
1024
-
}{{#unless @last}},{{/unless}}
1025
-
{{/each}}
1134
+
{
1135
+
#
1136
+
each
1137
+
(state
1138
+
context=
1139
+
'list'
1140
+
property=
1141
+
'list'
1142
+
default=
1143
+
'[]'
1144
+
)
1145
+
}
1146
+
}
1147
+
{
1148
+
"id": {
1149
+
{
1150
+
id
1151
+
}
1152
+
},
1153
+
"firstName"
1154
+
:
1155
+
"{{firstName}}",
1156
+
"lastName"
1157
+
:
1158
+
"{{lastName}}"
1159
+
}
1160
+
{
1161
+
{
1162
+
#
1163
+
unless
1164
+
@last
1165
+
}
1166
+
},
1167
+
{
1168
+
{
1169
+
/unless
1170
+
}
1171
+
}
1172
+
{
1173
+
{
1174
+
/each
1175
+
}
1176
+
}
1026
1177
]
1027
1178
```
1028
1179
@@ -1080,11 +1231,13 @@ This extension is at the moment not optimized for distributed setups or high deg
1080
1231
that should be held into account:
1081
1232
1082
1233
- The store used for storing the state is on instance-level only
1083
-
- while it can be exchanged for a distributed store, any atomicity assurance on instance level is not replicated to the distributed setup. Thus concurrent operations on different instances might result in state overwrites
1234
+
- while it can be exchanged for a distributed store, any atomicity assurance on instance level is not replicated to the distributed setup. Thus concurrent
1235
+
operations on different instances might result in state overwrites
1084
1236
- Lock-level is basically the whole context store
1085
-
- while the lock time is kept small, this can still impact measurements when being used in load tests
1237
+
- while the lock time is kept small, this can still impact measurements when being used in load tests
1086
1238
- Single updates to contexts (property additions or changes, list entry additions or deletions) are atomic on instance level
1087
-
- Concurrent requests are currently allowed to change the same context. Atomicity prevents overwrites but does not provide something like a transaction, so: the context can change while a request is performed
1239
+
- Concurrent requests are currently allowed to change the same context. Atomicity prevents overwrites but does not provide something like a transaction, so: the
1240
+
context can change while a request is performed
1088
1241
1089
1242
For any kind of usage with parallel write requests, it's recommended to use a different context for each parallel stream.
0 commit comments