-
-
Notifications
You must be signed in to change notification settings - Fork 481
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
Ending a state definition #497
Comments
The state only applies to the proceeding interaction. The next So .given("mystate")
.uponReceiving("post my request") // This interaction has state 'mystate'
.matchPath("/api/.+/.+/.+")
.method("POST")
.willRespondWith()
.status(200)
.body("string result")`
.uponReceiving... // This interaction will have no state, as it resets the state and there was no preceeding .given call |
That might be the idea but it is not how it currently works, in consumer-junit 3.5.2 all 3 uponReceiving following my test state got the following in the JSON:
|
That's a defect then. |
@uglyog I just saw this as well, with version
Results in the following pact file:
|
The problem seems to be here: pact-jvm/consumer/src/main/kotlin/au/com/dius/pact/consumer/dsl/PactDslResponse.kt Line 339 in c77faa7
It is starting a new interaction using the previous |
@solarmosaic-kflorence good catch! |
Released 4.1.24 and 4.2.9 |
@uglyog confirmed: {
"consumer": {
"name": "consumer"
},
"interactions": [
{
"description": "GET /hello-user",
"request": {
"method": "POST",
"path": "/hello-user"
},
"response": {
"body": {
"hello": "user"
},
"status": 200
}
},
{
"description": "GET /hello",
"providerStates": [
{
"name": "greeting",
"params": {
"name": "world"
}
}
],
"request": {
"method": "POST",
"path": "/hello"
},
"response": {
"body": {
"hello": "world"
},
"status": 200
}
}
],
"metadata": {
"pact-jvm": {
"version": "4.2.9"
},
"pactSpecification": {
"version": "3.0.0"
}
},
"provider": {
"name": "example"
}
} I think this ticket can be closed. |
In pact-jvm-consumer-junit (and others?) there is currently no way to end a "given" definition, this makes it easy to accidentally place more requests that should'nt be in that state.
One way around this is using states for all requests but I don't think that should feel as forced as it currently is.
The text was updated successfully, but these errors were encountered: