Coder Social home page Coder Social logo

Comments (13)

neilcampbell avatar neilcampbell commented on August 23, 2024

@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.

bethesque avatar bethesque commented on August 23, 2024

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.

uglyog avatar uglyog commented on August 23, 2024

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.

xelibrion avatar xelibrion commented on August 23, 2024

@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.

uglyog avatar uglyog commented on August 23, 2024

For reference to this pact-foundation/pact-jvm#85
Google groups thread: https://groups.google.com/forum/#!topic/pact-dev/Dop34iwT3BE

from pact-net.

neilcampbell avatar neilcampbell commented on August 23, 2024

@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.

bethesque avatar bethesque commented on August 23, 2024

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.

uglyog avatar uglyog commented on August 23, 2024

@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.

xelibrion avatar xelibrion commented on August 23, 2024

@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.

bethesque avatar bethesque commented on August 23, 2024

Sounds like a good idea.

from pact-net.

neilcampbell avatar neilcampbell commented on August 23, 2024

@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.

bethesque avatar bethesque commented on August 23, 2024

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.

neilcampbell avatar neilcampbell commented on August 23, 2024

@bethesque Ok cool. I will create a specification test and PR for it, that way it is explicit.

from pact-net.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.