has joined #pact-msw-adapter

has joined #pact-msw-adapter

has joined #pact-msw-adapter

has joined #pact-msw-adapter

Trying to run these commands locally, getting this error ```? pact-msw-adapter git:(main) yarn run example:link yarn run v1.22.19 $ cd examples/react && yarn link @pactflow/pact-msw-adapter warning package.json: No license field error No registered package found called "@pactflow/pact-msw-adapter".```

I successfully ran `yarn` and even `yarn run example:install` first, but still getting this error

resolved: I failed to `yarn link` first, my bad

Has anyone ran the unit tests successfully with the vscode debugger? I'm seeing "debugger attached" messages in the console, and the tests are running successfully, but the program is not stopping at the breakpoints I'm setting. @yousafn could you share your `.vscode/launch.json` if you've gotten this to work?

You guys use forks for pr's right?

Ok so I've opened a pull request but I'm not close to done yet, just want to track my work. I've got a basic graphql api working and now I just need to: 1. capture the requests with msw 2. write the unit test with this captured request 3. write the transformer to make it pass https://github.com/pactflow/pact-msw-adapter/pull/125/files

Hello dude! I?ve not used the debugger personally for this project (and I?ll be honest, don?t use it generally - never taken the time to really bother to work out how it works xD) When I was developing I just had my fe end demo app open, which was yarn linked and I was hot reloading on source changes. Happy to help take a look though and get familiar!

Cheers dude! Thanks for this! You may wish to convert to draft whilst its a WIP and its a sign to users that its not ready for a merge review but people can collab. (I learned about that feature recently)

It's ok, I'll try messing with it again once I have time

thanks, done

I'm gonna put this on the shelf for the weekend, but could you take a https://github.com/pactflow/pact-msw-adapter/pull/125/files @yousafn? Do `yarn install` and then `yarn test ./src/pactFromMswServerGql.msw.spec.ts`; notice how there aren't any requests being matched at all? Not even with `{ onUnhandledRequest: 'error' }` set in the msw server? The https://github.com/mswjs/examples/issues/63says the problem is in how the Apollo Client is setup, but you can see I'm passing in `node-fetch` to the client just fine in `graphqlClient.ts`. I'd like to write the logic for handling gql, but msw isn't seeing any requests, which means I cannot write any handlers for it yet. Thanks

Figured this out; apparently my debug statement inside `graphqlClient.ts` was making a request which was throwing off msw. Removing this code made it work

got MSW working with graphql in pact-msw-adapter wooo ``` PASS src/pactFromMswServerGql.msw.spec.ts API - With MSW mock generating a pact ? should get all books (34 ms)``` now to write and test the pactfile

Ahh nice! I didn?t get a chance over the weekend, doing some gRPC things today/tomorrow. Glad you are moving forward now. Hope its enjoyable :slightly_smiling_face:

ahh I remember that moment when I was hacking - its a good feeling!

It's fun so far yeah

So I wrote the msw pact writefile test, and uh, it... passes? I was expecting it to fail. Does this pactfile look right? Again https://github.com/pactflow/pact-msw-adapter/pull/125/files for reference. You can run this test with ```yarn install yarn test ./src/pactFromMswServerGql.msw.spec.ts```

Hey not sure why you were expecting it to fail, could you elaborate? Just been taking a little look now which I?ve got time on and off this evening. Suppose the next step is checking we can verify this on the provider side and we can work out any of the finessing bits.

I didn't know if it would generate a pact file but it did

Yeah I can try that next

so as long as you make the right request in your test, you will just get returned the response, and have pact file data to write. If the wrong client request is made, there are no pact files to write. if you were doing something with the provider response in your system under tests, you can assert on that (given the returned mock response) and assert those expectations are correct. That would exercise you have the sent the correct request (and would serialise a pact file if calling writeToPactFile) and its on the developer to ensure there are appropriate unit test level assertions on the consumer side

just going to grab some tea and then I?m going to run this example https://github.com/pact-foundation/pact-js/tree/master/examples/graphql and check out the pact files that get that spat out, and work backwards from that, do a pact verification and see what if is different, if anything in the files generated by Pact and those crafted by msw-adapter

So that is looking good - got a provider verification hooked up and failing on matchers, which is to be expected, pact-msw-adapter was designed to be used for bi-directional so with swagger-mock-validator or PactFlow, which would deal with the matchers. `x-powered-by header` can be excluded from capture with a header whtelist

working from this branch https://github.com/pactflow/pact-msw-adapter/tree/gql-scratchpad that?s me done for now on this for the night, hope that helps you move along! :slightly_smiling_face:

I updated the gql example in the pact-js repo to use some of the latest deps https://github.com/pact-foundation/pact-js/pull/1124 It needs to move to the apollo/client on the consumer side but that is a yak shave for another day

Thank you! I'll dig into this again tomorrow

So it looks like to me not much needs to be done to `pact-msw-adapter` itself for graphql - it seems to just work out of the box?

also how to fix the matchers? I thought `pact-js` had a matchers api that can match the body string type instead of the string itself?

Hey @matt.fellows @yousafn MSW just released a major upgrade that depends on the built in fetch in nodejs 18 https://mswjs.io/blog/introducing-msw-2.0/

awesome, thanks for sharing. really well written post. i?ve wanted to to upgrade to support msw 1.x for a while but this will probably mean it?s worth jumping to 2.x i?d also like to drop support for node 16 and below as it?s eol. not sure when i?d get the time to look at it, at the moment so might be worth raising an issue to track on the repo :ok_hand::skin-tone-5:

Anytime, I've been enjoying digging into this project I might take a look when I have time

has joined #pact-msw-adapter

has joined #pact-msw-adapter

has joined #pact-msw-adapter

Hi there. Is it possible to change the path that?s reflected in the pact file? I?m using the bi-directional approach. With the consumer tests, using MSW I?m intercepting a URI that looks like this `https://base-url.com/service/v2/price/` . The tests run, and the pact file is generated. The path property for each endpoint defined as follows: `"path": /service/v2/price/` On the provider side, the path in the OAS doc is displayed simply as `/price/` (without the leading `/service/v2/`). My problem: The `can-i-deploy` step fails due to the endpoint `/service/v2/price/` not existing in the provider spec. Strictly true, but I?d like to get rid of the leading `/service/v2/` . Can I do this programmatically?

yes but not with this library as it stands. easiest way would be to use something like jq or sed on the command line and change the value, prior to publishing the pacts to your broker i suppose the pact msw adapter interface could allow you to override request data that is used for msw?s matching, and store that in a pact with caveats in place that this is a relatively dangerous thing to do and should be used in caution.

Okay, interesting. I think I?ll go down the jq route. Thanks!

for anyone else who runs into this problem, here?s how I got it working: ```pact=$(cat path/to/pact.json) && jq '.interactions[].request.path |= sub ("(^\/service\/v2\/)"; "\/")' <<<$pact > path/to/pact.json```