Comments (13)
@xelibrion Yeah it's a good question and I remember having a conversation about this at some point with someone else, but cant remember the exact outcome. Based on the pact specification for v2 (which we are currently not checking on just yet) the current behaviour is correct. https://github.com/bethesque/pact-specification/blob/version-2/testcases/request/body/no%20body.json. @bethesque Can you confirm that this is correct? Postel's law is making me question this one.
from pact-net.
I think you're right @neilcampbell, @uglyog, this doesn't seem right https://github.com/bethesque/pact-specification/blob/version-2/testcases/request/body/no%20body.json
from pact-net.
When there is no expectation on the body (as opposed to expecting an empty
body), then surely it must match regardless if you receive a body or not?
On 3 September 2015 at 07:35, Beth Skurrie [email protected] wrote:
I think you're right @neilcampbell https://github.com/neilcampbell,
@uglyog https://github.com/uglyog, this doesn't seem right
https://github.com/bethesque/pact-specification/blob/version-2/testcases/request/body/no%20body.json—
Reply to this email directly or view it on GitHub
#47 (comment).
from pact-net.
@neilcampbell @bethesque @uglyog I think there actually might be two parts to this question. First one is matching registered interaction with actual request on consumer side, and the second one is matching consumer expectation and provider response.
As for the latter one, it is perfectly fine to have extra fields or entire body in the response in my opinion, but I don't think that exactly the same rules should apply to the former, although I can see that it might be questionable and we potentially might need two modes of interaction matching on consumer side (strict/non-strict).
from pact-net.
For reference to this pact-foundation/pact-jvm#85
Google groups thread: https://groups.google.com/forum/#!topic/pact-dev/Dop34iwT3BE
from pact-net.
@xelibrion I had a bit of a think through what we discussed on the weekend in relation to matching the correct request with response for the mock. We could definitely do what we talked about, however it would deviate from the what the specification outlines (which I don't want to do). See item 2 in Handling Requests https://github.com/bethesque/pact-specification/tree/master/implementation-guidelines#handling-requests
from pact-net.
There's a difference between an expectation of a null body, and no expectation for the body. I think (correct me if I'm wrong Ron), if you expect a null request body, then you should get a null request body. If you make no expectation on the request body, then I think we're not checking it at all. When the request is replayed though, it's going to have a null body, rather than whatever the actual request was, which makes it potentially buggy.
from pact-net.
@bethesque That's correct. If the body field is missing from the pact file, it can be anything because we are not checking it. It does not have to be null.
from pact-net.
@neilcampbell Fair enough. To solve the problem that I had (spending two hours debugging PactNet because I've forgotten to specify body for a POST request in expectation) is not necessary to change expectation matching rules - would be enough to display a warning/suggestion in test output that body was empty in expectation, but it was present in actual request. Would make dev onboarding slightly easier.
from pact-net.
Sounds like a good idea.
from pact-net.
@bethesque @uglyog Was just looking at closing this issue and implementing a fix for some of the stuff discussed and wanted to confirm a couple of behaviours.
I can see that when no body has been specified we don't go any further with regards to checking the body (https://github.com/bethesque/pact-specification/blob/version-2/testcases/request/body/no%20body.json), which is the current behaviour for PactNet.
Now if I explicitly set the expected body to null, should I ensure that the actual body is null as well and serialize that in the pact file ("body": null)? Is there a specification test for both request and response to show this scenario?
from pact-net.
I'm not sure if there's a specification, but the behaviour you described in the last paragraph is the behaviour of the Ruby impl.
from pact-net.
@bethesque Ok cool. I will create a specification test and PR for it, that way it is explicit.
from pact-net.
Related Issues (20)
- Wrong result validation when publishing pacts? HOT 11
- 'WithSslVerificationDisabled' doesnt disable ssl verification HOT 12
- Pact testing of protobuf messages failing due to content type JSON HOT 4
- Pact Merging Creates Duplicate Interactions HOT 3
- RFC: Pact Plugins HOT 6
- Pact json being overwritten by each test in C# .NET HOT 7
- Pact request body with inner object gives internal server error in Pact Net HOT 6
- Dynamic date in request HOT 3
- RFC: Add linux-musl-x64 Runtime Support HOT 3
- RFC: Add Linux (libc)-ARM Runtime Support HOT 2
- RFC: Support System.Text.Json default polymorphic type discriminator when using .WithJsonBody() HOT 2
- DevContainer: Unable to load shared library 'pact_ffi' or one of its dependencies HOT 1
- DevContainer: Unable to load shared library 'pact_ffi' or one of its dependencies wit PactNet.5.0.0-beta.2 HOT 2
- Match.Type throws an exception on an attribute of type Object HOT 3
- Version 5 roadmap HOT 1
- RFC: Distinguish technical failures when verifying pacts HOT 6
- RFC: add failIfNoPactsFound flag to Provider tests HOT 3
- Multiple integrations with same Consumer and Provider cause to pact file write errors HOT 7
- RFC: EachKey and EachValue Matcher HOT 1
- Documentation Confusion HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pact-net.