has joined #pact-js

has joined #pact-js

/github subscribe pact-foundation/pact-js

/github unsubscribe pact-foundation/pact-js commits

/github unsubscribe pact-foundation/pact-js commits

/github unsubscribe pact-foundation/pact-js deployments public

has joined #pact-js

has joined #pact-js

has joined #pact-js

has joined #pact-js

@rgshah781988 shared a file: https://pact-foundation.slack.com/files/UALL53S58/FALLGS7TL/i_am_getting_error__while_creating_a_pacts_file_.txt and commented: Response body - i have use :

has joined #pact-js

@rgshah781988 that error message has nothing to do with pact

that's an assertion error

exactly

must be coming from your tests

you?re not properly handling the promise, it seems

if you can share your test code, we can probably help

@rgshah781988 uploaded a file: https://pact-foundation.slack.com/files/UALL53S58/FAMNBFSFR/spec_js.txt

but remember that we're not here to fix your tests for you, there's plenty of documentation out there, so please try your best before bringing it to us as we're busy as well :slightly_smiling_face:

Yes sure

I got stuck since 5 days

@rgshah781988 uploaded a file: https://pact-foundation.slack.com/files/UALL53S58/FALQYMU05/index_js.txt

did you follow an example on how to use pact?

Yes

When I use matchers

`const { Pact, Matchers } = require('../../../dist/pact')` ...this doesn't seem right..

THen i am facing issue

can you post the link of the example you're following?

Actually, Example is working.

pact-foundation e2e folder

I am trying my application with it.

I am getting pact file creating successfully without using matchers

...I asked for the link to the example

When I use matchers then I am getting error.

right. An where in this example are we doing `expect(response.data).to.eql(EXPECTED_BODY)`?

As per this , I did implementation in my project : https://github.com/pact-foundation/pact-js/blob/master/examples/mocha/test/get-dogs.spec.js

so, you took 2 different examples and mashed it together

I have updated code as per this details

the line before `expect(response.data).to.eql(EXPECTED_BODY)`, add this: `console.log(JSON.stringify(response.data, null, 2));console.log(JSON.stringify(EXPECTED_BODY, null, 2));`

run the example again

This example , I need to use matchers

and see if they're equal

Expect condition is failing. I am getting console response

anywho, I need to get home. I suggest that you try to understand how pact works before you start combining tests together. There's plenty of resources out there

the expect is failing because the objects are not the same

one is the pact definition, the other is the action object coming from the mock

they're 2 different things

one explains the format, the other returns the end results

Thanks you so much @mboudreau

point is, you're not suppose to do an expect on the whole object

do an expect on individual properties

or keys if needed

but really, by adding those tests, you're not testing your code, you're testing the mock service. We have plenty of tests for those, and I assure you they work. You should be testing your own code

I think we should update the examples. The original `dog api` examples are so contrived they are useless - i.e. they encourage testing the whole object. I?ll put an issue in pact-js for us to fix them

:point_up:

ok

How can I get dynamic response from pact files ? I tried using matchers such as like,eachlike

I am working on API which has POST call with different payload values.

According response changes.

has joined #pact-js

has joined #pact-js

you don't. The point of pact is to generate a new response for each different request, hence you're now mapping all of the "interactions" as part of the "contract"

you can reuse responses if you'd like for a different interaction though

I think ?dynamic response? isn?t quite what you mean :slightly_smiling_face: You have - variable request (on parameters), and - deterministic response fields (constant, or from parameters), or - flexible response fields (?dynamic? such as a fresh ID).

for all response fields, you may want to use a flexible matcher

That's fine @rgshah781988. Just make a different interaction (request/response) for each different POST example. If the post is to the same URL, you'll need to make sure that only one interaction is mocked at a time, so the mock knows which response to return. That is, you'll have to do a set up/tear down for each interaction (which is actually the recommended way to use pact anyway).

Yes, This what I expect

So, how to do flexible matcher

Have a look in the docs: https://github.com/pact-foundation/pact-js#matching There?s an example under the heading *Match based on type* :slightly_smiling_face:

ok tysm

Just released a neat little video showing some of the features of Pact JS and integration with the broker: https://github.com/pact-foundation/pact-js/#examples

Useful?

Pact JS and integration with the broker . All inforamtion is clear with pact-broker

:+1:

Having the console recording is nice, but with no scrub bar, it all disappears before I can read it :slightly_smiling_face:

Maybe https://asciinema.org/ would be easier to use?

that?s what I used to create it. The annoying thing about asciinema is that it doesn?t play - I should probably like to it though, good point

you mean there?s no embeddable player? http://asciicinema.org is covered in them :s I thought it was part of the package

As in, you can?t embed the player into a GitHub README (or maybe you can now). You can only put the image and a link

That?s why the SVG plugin exists - because it plays, so you can see it

so the best of both words is the SVG in the readme (because it looks sexy and can play) and a link to the player, where you can control the speed?

right, because you need to source the player script

I guess you could iframe it . . . nothing but hacks to workaround that :stuck_out_tongue:

but if the svg linked to a player, I think that?d be good enough

No update or message in pacts js since last 7 days :sunglasses: Is anyone working with pactjs or not ?

@rgshah781988 hehehe

People still migrating (and using) the gazillion other channels they were communicating to us on.

But I like to think, it?s so amazing and easy to use, that noone needs to ask questions about pact-js :slightly_smiling_face:

@matt.fellows gazillion ? can you share link of it ? I can find some solution or help.

what do you mean, sorry?

I was just remarking that the move from gitter/google groups/etc. to Slack is new, so it?s still new place to grow this community, hence not many conversations yet

has joined #pact-js

has joined #pact-js

hi guys

how do i add authorization headers to access my endpoint to verify

@avinash.eediga could you please provide more info? Also, have you seen `customProviderHeaders` in https://github.com/pact-foundation/pact-js#verification-options?

please also read https://docs.pact.io/faq#how-do-i-test-oauth-or-other-security-headers

Can I match based on the key? For example, I have a payload that returns with `{"monthJan":5}`, and every month that key will change (monthFeb, monthMarch, etc..)

you can match using a regex

wait, I think that might be on the value, not the key

Yep, you can?t do it on the keys yet I?m afraid. That?s something slated for v4 of the spec: https://github.com/pact-foundation/pact-specification/tree/version-4

@brentbarker9 is there a way to change the data structure? I can't imagine monthJan/monthFeb/etc to be a great way of doing it since the key changes. It's adding more complexity than needed. What are you trying to accomplish with this data structure?

Yeah, talked to the dev. They are going to change the data structure to make a little more sense and not have the keys dynamic

Very cool it is going to be in v4 though

thanks!

has joined #pact-js

has joined #pact-js

has joined #pact-js

is it possible to pass query parameter values in array ? something like this `page=[1]&limit=[25]&fql=[]`

It should just be a string

I don't think it would be treated any differently to any other string.

`{page: "[1]"}`.

Are you trying to work around some limitation in pact, or is that what your API requires?

this is what my API requires

Should be fine. Why do you ask? Have you had problems?

no problem.. i just wanted to try that

has joined #pact-js

Doesn't sound very consumer-driven :P

has joined #pact-js

Hi, I am new on pact. I am having some issue with regex matching on a request, is not matching any other value after the one specified in generate. I noticed if I remove manually from the json the [0] it then start to work. how should I setup in order to allow any value to be match? any idea?

Something is wrong with the serialisation of the query. It should be an object, not a string. @matt.fellows does pact js turn the query in to a string, or does it pass the object through?

I'll double check Beth. It should turn it into an object

@wchuang can you post the mock service logs?

@bethskurrie this is what the framework serialises before sending over the wire to the mock service: ``` "request": { "method": "GET", "path": "/animals/available", "query": { "page": { "json_class": "Pact::Term", "data": { "generate": "1", "matcher": { "json_class": "Regexp", "o": 0, "s": ".*" } } } } } ```

I?m not treating query strings any different to regular parameters, and to my eyes that looks to be consistent

Yep, it looks fine to me.

@wchuang what you see in the pact is not what the mock service uses for matching. The pact is written after the request matching is done.

also that matcher is pretty useless (it?s a regex that matches everything) - you might as well just match on type with `like('1')` which basically matches any string

@wchuang do you mean that when you modify the pact, it fixes your _consumer_ test or the _provider_ verification test?

I?ve just tested that locally anyway using the e2e examples in the repository, and the consumer test passes just fine

sorry for the delay

15:36:36 [INFO] ===> Received request: Request { method: "GET", path: "/api/objects", query: Some({"page": ["2"]}), headers: Some({"Authorization": "Basic Og==", "Content-Type": "application/json", "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36", "Accept-Encoding": "gzip, deflate, br", "Cache-Control": "no-cache", "Accept-Language": "en-US,en;q=0.9,it;q=0.8", "Postman-Token": "c9ebfe6b-d8c6-000c-5d03-b31d268636c3", "Accept": "*/*", "Connection": "keep-alive", "Host": "localhost:18119"}), body: Empty, matching_rules: MatchingRules { rules: {} }, generators: Generators { categories: {} } } 15:36:36 [INFO] body: '' 15:36:36 [INFO] comparing to expected request: Request { method: "GET", path: "/api/objects", query: Some({"page": ["1"]}), headers: None, body: Missing, matching_rules: MatchingRules { rules: {"query": Category { name: "query", rules: {"page[0]": RuleList { rules: [Regex(".*")], rule_logic: And }} }} }, generators: Generators { categories: {} } } 15:36:36 [WARN] No matching request found, sending 404 Not Found

thanks :slightly_smiling_face:

I used the regex, because now I am matching anything, but in long term i want to also do assertation on the string itself. i am trying now with like

service | ===> Received request: Request { method: "GET", path: "/api/objects", query: Some({"page": ["2"]}), headers: Some({"Postman-Token": "866f0fef-1ecd-122c-801b-4480d74c63d2", "Authorization": "Basic Og==", "Accept": "*/*", "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36", "Host": "localhost:18119", "Accept-Encoding": "gzip, deflate, br", "Accept-Language": "en-US,en;q=0.9,it;q=0.8", "Connection": "keep-alive", "Content-Type": "application/json", "Cache-Control": "no-cache"}), body: Empty, matching_rules: MatchingRules { rules: {} }, generators: Generators { categories: {} } } service | 16:27:40 [INFO] body: '' service | service | 16:27:40 [INFO] comparing to expected request: Request { method: "GET", path: "/api/objects", query: Some({"page": ["1"]}), headers: None, body: Missing, matching_rules: MatchingRules { rules: {"query": Category { name: "query", rules: {"page[0]": RuleList { rules: [Type], rule_logic: And }} }} }, generators: Generators { categories: {} } } service | 16:27:40 [WARN] No matching request found, sending 404 Not Found

no matching with Like, use somethinglike could not a like

withRequest: { method: 'GET', path: '/api/objects', query: { page: somethingLike('1') } },

that the test

and this is the json generated "description": "Get object", "request": { "method": "GET", "path": "/api/objects", "query": "page=1", "matchingRules": { "$.query.page[0]": { "match": "type" } } },

I just call with /api/objects?page=2

on the consumer test works, I need then to start the mock service and use is like the real one, here is failing

@wchuang which implementation are you using?

Those aren't the mock service logs from the ruby implementation (used by pact-js)

Hi beth, sorry for the misunderstanding, as said at the beginning I am new to pact :stuck_out_tongue: I have talked with my qa team, and basically we are using the pact-stub-server to then run the json file. that log come from there

I guess here is the prob, do you know if these are compatible to be use in that way?

Oh! You'll need @uglyog to help you with that.

k thanks beth for our help :slightly_smiling_face:

this happens when we use the pact files with stub-server

has joined #pact-js

has joined #pact-js

has joined #pact-js

has joined #pact-js

cross-posting from #general : https://pact-foundation.slack.com/archives/C5F4KFKR8/p1531428184000342

So yep, basically that?s the right one

Cool. You mentioned avoiding karma-pact when possible. Why is that?

Well it?s just a bit more complicated to setup and has some restrictions. The reason is that inside Karma you don?t have access to the filesystem, so you need to configure Pact in your client test and in the Karma config (which starts the mock server, logs etc.). But the big one for me is that it encourages testing via UIs (end-to-end / acceptance style) rather than testing _just_ the collaborating components using pure JS

ohhhh

:ewww:

yeah I?d like to avoid a UI

hehe

that?s not to say that `karma-pact` means you have to test via the UI, but Karma most often is associated with it. If you know what you?re doing (i.e. can structure your tests appropriately) then you?re good :slightly_smiling_face:

right on

thank you for your time! this is helpful info

no worries!

Now, I think I?ve seen your name from somewhere before - you?ve been using Pact for a while yeah?

yessir I have, and with pleasure :simple_smile:

:smile:

Have I seen you on the Pact Broker forums maybe? (i.e. the forum for the hosted product http://pact.dius.com.au ? which is now #pact-broker)

I think you and Beth did a video ?intro to Pact? meeting with us a while ago (for Instructure). Also I?ve asked a few questions in the Google Group and Stackoverflow.

aha! Yes that?s it

thanks to Pact we?ve scaled back our E2E test suite and moved almost all of them to run on deployed ?staging? and ?prod? environments only. So much faster CI!!

Where in discussions with Robert Lamb at the moment

oh cool, that?s really great to hear

excellent, yeah Robert?s leading the Pact adoption for our flagship product

speaking of whom, I have a meeting with him right now :smile:

haha ok

Thanks again, matt! Really appreciate all your help.

say hi (and let him know that when it?s daylight here i?ll be talking with out people about how we can help :smile: )

has joined #pact-js

Hi, I?m trying to integrate Pact JS into a React project. It worked well until I tried to build the application with Jenkins. When I execute `yarn install` I get the following error: ``` `Postinstalled Failed Unexpectedly: Extraction failed for /var/lib/jenkins/workspace/.../node_modules/@pact-foundation/pact-node/standalone/pact-1.52.1-linux-x86_64.tar.gz: Checksum rejected for file 'pact-1.52.1-linux-x86_64.tar.gz' with checksum pact-1.52.1-linux-x86_64.tar.gz.checksum` ``` I doubt that this a Pact JS issue, I?d rather blame Jenkins or Nexus. But I was hoping that maybe you have seen this before and could give me a useful hint how to resolve this. Thank you in advance!

It would be worth trynig to get your hands on `/var/lib/jenkins/workspace/.../node_modules/@pact-foundation/pact-node/standalone/pact-1.52.1-linux-x86_64.tar.gz`

Perhaps there is an intermediate proxy or something and it?s not properly downloading it, so when it does the validation it?s incorrect?

Thank you @matt.fellows! Unfortunately, the workspace is already gone and I can?t reproduce the issue. I can see that this file has been downloaded from https://github.com/pact-foundation/pact-ruby-standalone/releases/download/v1.52.1/pact-1.52.1-linux-x86_64.tar.gz. Maybe it was a temporary issue with GitHub or any network/firewall component that corrupted the artifact.

the old ?turn it on and off again? trick - no worries, glad it?s up and working :slightly_smiling_face:

It?s safe to assume that it was a temporary GitHub issue: https://status.github.com/messages ``` Jul 16, 2018 7:44 PM 20:04 CEST We've discovered the issue causing connectivity failures and are remediating. ``` Thank you for your support! :+1:

no worries

has joined #pact-js

has joined #pact-js

what?s the status of the pact js framework in terms of supporting parallel tests ? the most prevalent example is jest

It?s possible, albeit you?ll need to follow the caveats outlined in the readme

it?s easiest if the parallelised tests are hitting a different mock endpoint

Easiest == only possible.

or `s/a different mock endpoint/a different mock provider`

you definitely need a different _mock endpoint_ to make tests against a single provider work.

see https://github.com/pact-foundation/pact-js#parallel-tests

alright. going to test that soon and will report back with feedback

Let us know how things go. I should be semi available later on tonight :laughing:

no rush, but appreciate it :wink:

has joined #pact-js

has joined #pact-js

has joined #pact-js

has joined #pact-js

how much ?beta? is pact-js 6 exactly? :slightly_smiling_face:

More production ready than beta.

It's just the message pact interface that might change. We were wanting more feedback

is there a PR or an issue opened on it which I should follow? and is there a list of items that need to land to make 6 ready?

has joined #pact-js

has joined #pact-js

has joined #pact-js

has joined #pact-js

Hi ,is it possible to create interactions in JS like this ?matchingRules?: { ?$.query.var1[0]?: { ?match?: ?regex?, ?regex?: ?.*? }, ?$.query.var2[0]?: { ?match?: ?regex?, ?regex?: ?.*? }, what should i pass in var 2 that my two api calls are successful http://localhost:${PORT}/api/objects?var1=0&var2=25 and http://localhost:${PORT}/api/objects?var1 Is it possible to do by provider states?

Rather than showing the expected pact file, let's start at the start. What's the goal of your test? You can definitely apply matchers to query strings if that's what you're asking

You'll probably want to use a type matcher also, rather than a regex if you don't care about the value

I want two tests to work .For example One uses only one parameter and other query uses two parameter .How do i do that

http://localhost:${PORT}/api/objects?var1=0&var2=25 and http://localhost:${PORT}/api/objects?var1

like this

one is to list the data and in other test we pass one more parameter of sorting

@dagarwal there isn?t any problem to do that. what?s your issue?

you define different interactions in different tests so there?s no reason why you can?t do what you just described

I tried the same way .It just creates only one response for two interactions

let me share the code with u

you should do: 1. set up interaction 2. run your test on the cdc 3. verify the interaction for each one single test case that you have

it?s a best practice regardless to cdc

I have shared the code with u

Did you want to share it with the channel so you can get the collective help of the community?

@matt.fellows it allows me to create only one json , m adding two interaction with diff query and same path

You don't need to run setup for each test. You should be able to run it once for the whole test suite. Secondly, each test is unique based on the `given` and `uponReceiving` values. You can differentiate then with different values and pact will then record them as unique interactions

has joined #pact-js

has joined #pact-js

has joined #pact-js

Cheers!

If there's any examples of larger code bases with Angular Karma and PactJS out there - i'd been keen to have a look!

Is this usually a fairly quiet channel over the weekend yeah?

Hehe yeah

No worries :stuck_out_tongue:

Ah, I thought I had responded to this. I have some ideas/tips but have not used it with karma in anger.

This might be of help https://github.com/pact-foundation/pact-js/blob/master/README.md#splitting-tests-across-multiple-files

The mock server that spins up is specific to each consumer/provider pair. So you can't reuse it for others. This is often the cause of strange behavior

The provider/consumer pair is unique. But it's specified at the top of each spec file like so : let provider; beforeAll(function (done) { provider = new PactWeb({ consumer: 'FRESUI', provider: 'FRESAPI', logLevel: 'info', port: 1234, host: 'localhost', }); // required for slower CI environments setTimeout(done, 2000); // Required if run with `singleRun: false` provider.removeInteractions(); }); afterAll(function (done) { provider.finalize().then(done, e => done.fail(e)); });

I had looked at the README but wasn't sure how to achieve the setup and teardown across all Karma Tests. As a sort of beforeAllTests

I'm not sure how much of a clue it is - but i get all sorts of failure spam on my console (Even on successful test pass).

I don't think you can at this point. I'd suggest setting up multiple pact servers (on different ports) in your karma config, and then link to the different servers in your tests. 1 for each mock server

Even with the same consumers? Is this just from a reliability standpoint?

It does seem to pass on occassion on the build servers, just not reliably

most people have the weekend off from work :wink:

for the same consumer/provider _pair_, yes. If you have different providers but the same _consumer_ then it?s likely to cause issues

In your Karma config, you?ll need a separate mock server for each unique consumer/provider combination. e.g. if you have two providers, something like this: ``` // Pact Providers pact: [{ port: 1234, consumer: 'Consumer', provider: 'Provider1', log: path.resolve(process.cwd(), 'logs', 'pact.log'), dir: path.resolve(process.cwd(), 'pacts') }, { port: 5678, consumer: 'Consumer', provider: 'Provider2', log: path.resolve(process.cwd(), 'logs', 'pact.log'), dir: path.resolve(process.cwd(), 'pacts') } ], ```

Karma is responsible for starting the mock servers. After that, the jasmine tests are responsible for wiring to the correct mock server

Shock horror :joy: I only ask to set my expectations right :wink:

Cheers Matt - i had a quick go last night but had some issues. On for another go now :slightly_smiling_face:

Actually - just re-read back there. In the tests my Consumer/Provider Pair IS the same. Is it still recommended for them to be on 2 seperate providers?

and yet, I?m sure if we reviewed commit history this is where the majority of commits are made :smile:

only for the good projects :wink:

:laughing:

I think i've figure out what's wrong. I had afterEach((done) => { provider.verify().then(done, e => done.fail(e)); }); In each of my tests when i was never looking to do this on my Angular tests. My intention was to create unit tests with the mock responses - generate a pact file, publish to broker and then verify the pact on the actual consumers CI Build.

So verifying the provider in the angular tests is pointless (Or is it, question for another day), and removing this resolves my issue

Hmm something doesn?t seem right here. `provider.verify().then(done, e => done.fail(e));`is not actually doing a provider verification, it?s checking that what you told the mock you were about to send to it in fact came through. If things are failing, that?s a cause for concern

if you could share a working example, or close enough to what you have it might be useful

Might also be worth reading https://github.com/pact-foundation/pact-js/blob/master/README.md#parallel-tests

Ah i did read afterwards that i may have misunderstood there. Perhaps there's a bug with this as it did seem to be fairly inconsistent with the results it provided. I'll hopefully get some time to dive into this again, i hit a bit of another snag with state management in the other thread too.

oh dear

if you have code that reproduces it, I can either help fix the bug, the docs or your code

I'll see if i can isolate it in a smaller repository - it may take me to the weekend to get round to it though

has joined #pact-js

Hello everyone. I have a question regarding using the `customProviderHeaders` . I am using it with AWS authentication, but I need each different request to be authenticated differently. How do I add a different provider header to each single interaction? Because basically, I need to dynamically add the headers according to information about the interaction I'm currently on. Is there a direct way to do this?

Yeah it?s a limitation at the moment. Currently you can?t do it per interaction, unless your verification step is split for each interaction (not easy to do)

could you please raise a request, I think I have a solution for working around how this works that could achieve this

i was thinking as a workaround of getting the json file from the pact broker in a separate function, running through it and dynamically adding the auth header, make a new (local json), and then use that path for the pactUrls instead. This should work right?

sure, where should I raise the request? pact-js repo ?

has joined #pact-js

has joined #pact-js

Yes please

Hello guys. I could use some help. I seem to have come across a weird bug, or maybe I am doing something wrong. We spent a while trying to debug it thinking it might be something we are doing on our side, but after debugging some of the code, I think it might be on pact-provider-verifier.rb , since I assume it is somewhere in there that it makes the HTTP request to my local server, but that's as far as we got. - I have a pact broker hosted on heroku (temporarily) deployed like this https://github.com/pact-foundation/pact_broker/tree/master/example , which i believe is using the latest version. - Since this is a Serverless project, we had to make a local server for the providerStatesSetupUrl. I am using the customProviderHeaders option to do AWS authentication. I need to pass in 3 headers. This is where it gets weird. I have to pass in 'Authorization' , 'X-Amz-Date' and 'Content-Type' headers. - If I just pass in the first 2, I can see that pact talks to my local setup server, and it passes it the state in the body of the request. This, however, won't work, since it needs the third header. - However, when I pass in the additional header 'Content-Type: application/x-www-form-urlencoded ' , for some reason, the state is no longer passed in the body of the request. It is being sent as an empty object {}, without the state. It appears if I send any Content-Type that isn't Content-Type/application-json, including some gibberish , the state gets passed as empty. Any clues?

has joined #pact-js

Morning all, having some issues getting Pact working with Angular 6 and Karma. See below for the log against the terminal, and the package.json file in the thread. I'm following the tutorial on the git hub page, using the Karma + Jasmine page to modify the other relavent files. Any help would be appreciated. Thank you

apologies in advance for any rookie mistakes, first time using JS/TS frameworks here

has joined #pact-js

has joined #pact-js

Hello all , I am getting ?Failed to load pact from ?pacts? - Failed to parse Pact JSON - expected value at line 1 column 1 ?error after docker pull , I have not made any changes in pact file .Any suggestions ?

has joined #pact-js

has joined #pact-js

Hi guys

I?m running into an issue and someone in general chat told me to ping you guys? https://stackoverflow.com/questions/52410277/error-with-typescript-pact-io-test-popsicleerror-unable-to-connect-to

Oh hah I see my issue posted above

"solved" :upside_down_face:

Did you ever work out what this is?

Did you ever solve this? Sorry for my delay, must of missed it

I think there is an issue on the repo that logs this issue. Why do you need to _actually_ auth to AWS for the provider verification? Can you stub it out?

hi @matt.fellows, no worries at all. Afraid I haven't been able to solve it no

yes it worked for me later

has joined #pact-js

has joined #pact-js

:+1:

I asked this in General, but realized this is the correct place to post this issue

But I?m getting the following Pact test errors: ``` console.error node_modules/@pact-foundation/pact/pact.js:110 Pact verification failed! console.error node_modules/@pact-foundation/pact/pact.js:111 Actual interactions do not match expected interactions for mock MockService. Missing requests: GET /frontoffice/api/liquidity-pool/get-total-payout ```

Hi @leon.gaban, the answer is in the error you are getting - your code (presumably `getTotalPayout`) is not hitting the Pact Mock Service endpoint `/frontoffice/api/liquidity-pool/get-total-payout`. It might be making an HTTP call, but it must not be calling the right thing (the Pact mock server).

ok I?ll work on mocking that endpoint today, thanks!

@matt.fellows are there any good examples you could pass on?

Hmm, `getTotalPayout` looks correct to me tho

and I have a `src/__mocks__/axios.ts` file ``` // tslint:disable-next-line:no-empty const mockNoop = () => new Promise(() => {}); export default { get: jest.fn(() => Promise.resolve({ data: { total_payout: 100.21 }})), default: mockNoop, post: mockNoop, put: mockNoop, delete: mockNoop, patch: mockNoop }; ```

I?ll post a new stackoverflow question (will change paths to hide real api), I need code example help at this point.

I will try create a small repo to reproduce this

Repo up! https://github.com/leongaban/pact-io-js-test

running into a no tests found error atm :confused: `No tests found`

This suggests you're mocking out axois completely, so no http call us going to be made. Hence why it's not making any http calls to the next mock server

Pact is expecting a call via http. It's pretending to be your provider and will respond when interacted with

Thanks Leon

I?ve responded on Stack Overflow

There are multiple problems with your code 1. Axios seems to be used, but is not in your package.json. I?m guessing because you?re mocking it out (2) 2. Axios is mocked out to provide canned responses, DO NOT mock out axios during Pact testing (it?s ok for local dev if y,ou want) as this will prevent real calls being made to Pact 3. Configure axios in tests to hit the Pact mock service. Something like pactSetup.ts: ``` // Configure axios to use the Pact mock server for Pact tests import axios from "axios"; axios.defaults.baseURL = "http://localhost:1234"; ``` 4. Read the log files that Pact spits out. It tells you what?s going on. To re-iterate: You?ve told Pact that there should be an interaction on 5. You might want to use Pact for a local stub server for local development, once you?ve started generating Pacts (after 1-4 are fixed). The binary is actually installed in your node_modules and the docs for how it operates are at https://github.com/pact-foundation/pact-ruby-standalone/releases I typically have a script in package.json that looks something like: ``` "stubs": "$(find . -name pact-stub-service | head -n 1) pacts/* --port 4000" ``` So that I can run `npm run stubs` and have a local stub of the provider running on port 4000

I?ve responded with the above and more on SO (https://stackoverflow.com/questions/52520827/pact-io-getting-missing-requests-error-when-running-npm-run-pacttest/52525869#52525869)

The rest is up to you mate!

How did you go @leon.gaban?

I?ll try to get it working this weekend, so I?ll remove the axios mock

while the README at `https://github.com/pact-foundation/pact-js` is for version 6, the installation instructions there are `npm i -S @pact-foundation/pact@latest` which will install version 5 since the `latest` tag is associated with that where-as 6 is tagged as pre-release

not sure if that?s intentional or not but I find it confusing

That is misleading, I'll get that fixed. Thanks Liran!

Thanks! anytime

:+1:

Fix on the way out for this process - thanks for the tip!

lol, thanks integration . . . > *Release - null*

right?!

Nice :)

has joined #pact-js

has joined #pact-js

so I?m thinking of deprecating node versions below `6` in the next release. It?s hard to keep dependencies up to date and secure, because a lot of them only support 6 or later. Thoughts?

Release train `6.x.x` can continue to support until it?s deprecated, and `5.x.x`will be deprecated (> 1 year old now)

@matt.fellows sounds like a good idea as 6 is anyway in maintenance mode.

so I guess new threshold will be 8?

5 is not relevant at all

I think 6 is still pretty common, so I?d prefer to start there unless good reason not to. Pact is used a lot in Enterprise environments, which can sometimes be a bit slower to upgrade/adopt

Part of the trigger, is I?m constantly finding myself (and others) to fix things to make it compatible - we?re fighting the system now, rather than flowing with it.

yep that?s true

I can see why 8 might be good - `async` etc.

nods

also, 6 will be unsupported by 2019 which is just a few months ahead

hmmm

Hmmm? this integration might be a bit noisy!

:stuck_out_tongue:

Was looking at some bots to automate versioning, staleness and triage issue/PRs - same :clock2:

yeah, I just got spammed with emails

Heaps of good ones at https://probot.github.io/apps

good job :wink:

sorry about that

i have pact tests which have get , Put request and for video functionality .It stops working if i go higher than v0.0.9 . anyone has any idea or faced this issue

Hi all - I wrote a proposal for improving the `pact-js` DSL - I'd be very interested in any thoughts: https://gist.github.com/TimothyJones/d138bf765509d41e0ce8a4bfb777a31d

Comments welcome on the issue here: https://github.com/pact-foundation/pact-js/issues/215

@matt.fellows hi matt, just to update you, i've managed to solve the above problem. The issue was in my *pact.spec.ts file i was trying to import Pact class from /pact instead of pact-web Using the equivalent PactWeb class is now allowing Karma to run without throwing up the errors in the previous attachement. However, when i come to try and create a broker for my tests, i'm required to use the Publisher class from pact-node module folder, doing this is bringing me back to the original problem of all those module not found errors in the terminal,. pact-web doesn't seem to have an equivalent for publishing to a broker, any ideas?

Hi Adam.

That?s great to hear! On the publishing topic, you would never want to be publishing pacts from `pact-web`, at least, it?s not an intended behaviour

> However, when i come to try and create a broker for my tests, Hmm, that doesn?t make sense. The broker is a hosted component (e.g. http://pact.dius.com.au or https://github.com/pact-foundation/pact_broker/), do you mean ?publish a pact?? > i?m required to use the Publisher class from pact-node module folder, doing this is bringing me back to the original problem of all those module not found errors in the terminal,. Yes, this won?t work in a non-node env (https://github.com/pact-foundation/pact-js/#using-pact-in-non-node-environments) > pact-web doesn?t seem to have an equivalent for publishing to a broker, any ideas? Yes, pact-web is just a DSL for the tests themselves, which when successfully run then produce a pact file. This is what gets published. It is recommended that only CI would publish pacts, so I would decouple the publishing (e.g. create a task `npm run pact:publish` from your test runs (`npm t`) - see https://github.com/pact-foundation/pact_broker/wiki/Set-up-checklist#consumer-team

thanks for the reply Matt, appreciate your help. Ideally would like to debug the publishing code locally, but it could be we need to look at not using Karma if we're wanting to do that. Thanks again :+1:

What do you mean by "debug publishing locally"?

Oh right, I mean you can still test it from your local, but you wouldn't normally attach the publish step to your testing code anyway. There's an e2e example in the project repo if you want to see an example though

we've got a http://pact.net implementation for our back end microservices, and our senior developer is setting up the entire pact test process from creation>verification>publishing as part of the test. This is allowing us to test that the broker is running the contract comparison against the consumer/provider correctly. I was attempting to do the same with our front end application (written in Angular). You think this approach is unwise in general or for simply a front-end application? Thanks

Just in general, you don?t want to be publishing pacts to the broker during development (i.e. TDD). Unless each time you run your test process locally you want to both publish the artifacts to the broker, and then run the provider verification (which seems very much overkill to me).

You might want to be able to set an environment flag (e.g. `CI=true`) to be able to test that the process works, or for setting it up in the first place

Hi, When i try provider verification like this, ```describe('Pact Verification', () => { it('should validate the expectations of Matching Service', function () { let opts = { provider: 'Animal Profile Service', providerBaseUrl: 'http://localhost:8081', pactBrokerUrl: 'https://test.pact.dius.com.au/', pactBrokerUsername: 'dXfltyFMgNOFZAxr8io9wJ37iUpY42M', pactBrokerPassword: 'O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1', publishVerificationResult: true, providerVersion: "1.0.0" } return new Verifier().verifyProvider(opts) .then(output => { console.log('Pact Verification Complete!') console.log(output) }); }); });``` i get an error ``` 1) Pact Verification should validate the expectations of Matching Service: TypeError: Must provide the providerBaseUrl argument at assertImpl (node_modules/check-types/src/check-types.js:730:11) at assertPredicate (node_modules/check-types/src/check-types.js:718:5) at Function.nonEmptyString (node_modules/check-types/src/check-types.js:710:14) at new Verifier (node_modules/@pact-foundation/pact-node/src/verifier.js:51:27) at Context.<anonymous> (test/pact/proververification.spec.js:26:14)```

what am i missing in this ? i have given providerBaseUrl in opts

hmm it looks ok to my eye

Can you please share an example project on GitHub I can use to reproduce the issue? (i.e. with package.json etc.)

yes @matt.fellows, https://github.com/vini46/PactProviderSample

OK I think the first problem is you?re not using the `@pact-foundation/pact` dependency, albeit it should still probably work

see https://github.com/pact-foundation/pact-js/blob/master/examples/e2e/test/provider.spec.js (it?s using a relative import, but that is the dependency from above)

Ah, you?re problem is you?re using the API that exists on the `@pact-foundation/pact` dependency, but calling it on the `@pact-foundation/pact-node` dependency

Whilst you?re passing the right options through, you?re passing them to `verifyProvider()` and not the `new Verifier(opts)` constructor. As soon as you fix the constructor problem, it will complain that the method doesn?t exist

TL;DR - change `const { Verifier } = require("@pact-foundation/pact-node");` to `const { Verifier } = require("@pact-foundation/pact");`

:ok_hand:

thanks @matt.fellows it worked :slightly_smiling_face:

@matt.fellows probably worth to document on the pact-foundation/pact-js github repo the different npms and what are they used for. The README on that repo also references @pact-foundation/pact-node in the broker publishing section

Thanks, I'll check today

has joined #pact-js

has joined #pact-js

Good evening, I?m trying to trouble shoot this request ``` describe('List of personal snippets', () => { beforeEach(() => { const interaction = { state: 'I have a list of snippets', uponReceiving: 'a request for all the snippets', withRequest: { method: 'POST', path: '/v2/searches/snippets', body: { type: 'personal' }, headers: { 'Content-Type': 'application/json', }, }, willRespondWith: { status: 200, headers: { 'Content-Type': 'application/json', }, body: EXPECTED_BODY, }, } return pactProviders.scintillas.addInteraction(interaction) }) it('returns a list of snippets', async done => { const fetched_data = await fetch(`${url}/v2/searches/snippets`, { method: 'POST', body: JSON.stringify({ type: 'personal' }), headers: { 'Content-Type': 'application/json' }, }) const response = await fetched_data.json() expect(response).toEqual(EXPECTED_BODY) pactProviders.scintillas.verify() done() }) }) ``` In this setup when I added to `withRequest` ``` body: { type: 'personal' }, headers: { 'Content-Type': 'application/json', }, ``` and ``` body: JSON.stringify({ type: 'personal' }), headers: { 'Content-Type': 'application/json' }, ``` to my `fetch` request. The provider doesn?t like it and it dies right after being created ``` [2018-10-16T23:00:38.974Z] INFO: pact-node@6.19.11/72860 on Marcos-MacBook-Pro.local: Created './standalone/darwin-1.54.4/bin/pact-mock-service service --consumer 'Rhapsody' --cors 'true' --pact_dir '/Users/marcodellolio/src/rhapsody/pacts' --host '127.0.0.1' --log '/Users/marcodellolio/src/rhapsody/logs/mockserver-integration.log' --pact-file-write-mode 'merge' --port '8001' --provider 'Scintillas' --pact_specification_version '2'' process with PID: 72882 [2018-10-16T23:00:40.051Z] INFO: pact-node@6.19.11/72860 on Marcos-MacBook-Pro.local: Removing Pact with PID: 72882 [2018-10-16T23:00:40.054Z] INFO: pact-node@6.19.11/72860 on Marcos-MacBook-Pro.local: Deleting Pact Server with options: ``` Should I parse my request in a particular way?

Most of the core maintainers are at an event today, so I'm not sure when you might get a solid reply :sweat_smile:

oh! thank you for letting me know, do you have a post request example I can confront mine with?

I'll have a look :slightly_smiling_face:

The most recent one I've got handy is from about a year ago . . .

``` describe('can add an thing', () => { // given: beforeEach(() => provider.addInteraction({ state: 'a view with two samplers', uponReceiving: 'request to add a thing', withRequest: { method: 'POST', path: '/view/0/sampler/1/thing', headers: headers.request, body: { type: 'interleaved', metrics: [{ type: 'event', name: 'view' }], variants: [{ name: 'jim', data: '' }, { name: 'bob', data: '' }], name: 'Some new thing' } }, willRespondWith: { status: 201, body: { id: like('0'), state: 'unscheduled' } } }) ); // when: it('', () => client.thing .add(0, 1, { type: 'interleaved', metrics: [{ type: 'event', name: 'view' }], variants: [{ name: 'jim', data: '' }, { name: 'bob', data: '' }], name: 'Some new thing' }) .then(body => { expect(body).to.eql({ id: '0', state: 'unscheduled' }); }) .catch(fail)); }); ```

and in the API client . . .

well, it's quite abstracted, and using `axios`

would that be useful too? or is this enough to work from?

I think so thank you! I just have to figure out how correctly parse the payloads

if you're not using `axios`, this may not be helpful, but here you go: ``` const mimeJson = 'application/json'; const headers = { 'Content-Type': mimeJson, Accept: mimeJson }; const GET = 'GET'; const POST = 'POST'; const PATCH = 'PATCH'; const DELETE = 'DELETE'; const transformBody = body => { if (body) { return JSON.stringify(body); } return null; }; const wrapRequest = (url, method = GET, body = null) => axios({ url, method, headers, data: transformBody(body) }) .then(resp => resp.data) .catch(error => { if (error.response) { // Made a request, but got a failure code if (error.response.data.message) { const errorMessage = { status: error.response.status, message: error.response.data.message }; throw errorMessage; } ... etc ```

what `transformBody(body)` does?

it's just above the `wrapRequest` function

oh sorry I missed it. Thank you

it just calls `JSON.stringify` if the body is truthy (mostly if it's not `null`)

As a quick note, to understand why it?s failing it might be worth setting logging to DEBUG and looking at the log files to see if there is any indication is to why it?s dying

Dying is not good :slightly_smiling_face:

``` [2018-10-17T01:53:47.261Z] INFO: pact-node@6.19.11/86087 on Marcos-MacBook-Pro.local: Creating Pact Server with options: consumer = Rhapsody, cors = true, dir = /Users/marcodellolio/src/rhapsody/pacts, host = 127.0.0.1, log = /Users/marcodellolio/src/rhapsody/logs/mockserver-integration.log, pactFileWriteMode = merge, port = 8001, provider = Scintillas, spec = 2, ssl = false, sslcert = , sslkey = [2018-10-17T01:53:47.262Z] INFO: pact@7.0.1/86087 on Marcos-MacBook-Pro.local: Setting up Pact with Consumer "Rhapsody" and Provider "Scintillas" using mock service on Port: "8001" [2018-10-17T01:53:47.815Z] DEBUG: pact-node@6.19.11/86087 on Marcos-MacBook-Pro.local: Starting pact binary with '/bin/sh,[object Object],... ..."NODE_ENV":"test","JEST_WORKER_ID":"1"}}' ```

``` [2018-10-17T01:53:47.819Z] INFO: pact-node@6.19.11/86087 on Marcos-MacBook-Pro.local: Created './standalone/darwin-1.54.4/bin/pact-mock-service service --consumer 'Rhapsody' --cors 'true' --pact_dir '/Users/marcodellolio/src/rhapsody/pacts' --host '127.0.0.1' --log '/Users/marcodellolio/src/rhapsody/logs/mockserver-integration.log' --pact-file-write-mode 'merge' --port '8001' --provider 'Scintillas' --pact_specification_version '2'' process with PID: 86109 [2018-10-17T01:53:48.664Z] DEBUG: pact-node@6.19.11/86087 on Marcos-MacBook-Pro.local: INFO WEBrick 1.3.1 INFO ruby 2.2.2 (2015-04-13) [x86_64-darwin13] [2018-10-17T01:53:48.664Z] DEBUG: pact-node@6.19.11/86087 on Marcos-MacBook-Pro.local: INFO WEBrick::HTTPServer#start: pid=86109 port=8001 [2018-10-17T01:53:48.909Z] INFO: pact-node@6.19.11/86087 on Marcos-MacBook-Pro.local: Removing Pact with PID: 86109 [2018-10-17T01:53:48.911Z] INFO: pact-node@6.19.11/86087 on Marcos-MacBook-Pro.local: Deleting Pact Server with options: consumer = Rhapsody, cors = true, dir = /Users/marcodellolio/src/rhapsody/pacts, host = 127.0.0.1, log = /Users/marcodellolio/src/rhapsody/logs/mockserver-integration.log, pactFileWriteMode = merge, port = 8001, provider = Scintillas, spec = 2, ssl = false, sslcert = , sslkey = [2018-10-17T01:53:48.913Z] DEBUG: pact-node@6.19.11/86087 on Marcos-MacBook-Pro.local: INFO going to shutdown ... INFO WEBrick::HTTPServer#start done. FAIL test/pact/consumer/scintillas.test.js ? Test suite failed to run Error: Timeout - Async callback was not invoked within the 10000ms timeout specified by jest.setTimeout. at mapper (../../node_modules/jest-jasmine2/build/queue_runner.js:41:52) Test Suites: 1 failed, 1 total Tests: 0 total Snapshots: 0 total Time: 13.27s Ran all test suites matching /test\/pact\/consumer\/scintillas/i. ```

it shuts down a second after, and obviously my fetch sends a request to not existing server

mmm

could you please try running the command it shows in the debug output? e.g. something along the lines of `./standalone/darwin-1.54.4/bin/pact-mock-service service --consumer 'Rhapsody' --cors 'true' --pact_dir '/Users/marcodellolio/src/rhapsody/pacts' --host '127.0.0.1' --log '/Users/marcodellolio/src/rhapsody/logs/mockserver-integration.log' --pact-file-write-mode 'merge' --port '8001' --provider 'Scintillas' --pact_specification_version '2'`

(you probably need to ensure the args are all correct but it _should_ start a server and wait. If it crashes, that might tell us what?s happening)

it?s possible there is perhaps a port conflict

I?m not sure what command I?m supposed to run. But as soon I remove ``` body: { type: 'personal' }, headers: { 'Content-Type': 'application/json', }, ``` from the request expectation and from the actual fetch post request, the test works correctly

It should start a server on port 8001

you should then be able to hit it e.g. `curl localhost:8001` and it should return something (an error saying it can?t find an interaction)

if that happens, that tells me something else is the problem

I?d say it?s something to do with the way your fetch thing is working

I suspect that too, because I applied the headers to fix this ``` {"interaction_diffs": [{"body": {"ACTUAL": "[{\"type\":\"personal\"}]", "EXPECTED": [{"type": "personal"}]}, "description": "a request for all the snippets", "provider_state": "I have a list of snippets"}], "message": "No interaction found for POST /v2/searches/snippets"} ```

because JSON.stringify(body) would not match my expected body

``` withRequest: { method: 'POST', path: '/v2/searches/snippets', body: [{ type: 'personal' }], headers: { Accept: 'application/json', 'Content-Type': 'application/json', }, }, ```

I was able to solve the problem using `superagent` as client for my request. Still no success with `axios` or `fetch`

has joined #pact-js

is there an npm module for `can-i-deploy` ? (https://github.com/pact-foundation/pact_broker-client#can-i-deploy)

I can?t spot anything odd with your fetch. are you still using superagent as a workaround?

Yeah, it looks ok to me.

Marco if you could please create a small project we can use to repro and raise an issue on pact-js, we?ll get to the bottom of it.

Update, looks like I was doing something odd with the beforeAll, afterAll hooks in Jest. I?m trying to spin up a mock provider for each service ``` global.pactProviders = { scintillas: new Pact({ port: 8000 + Number(process.env.JEST_WORKER_ID), log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'), dir: path.resolve(process.cwd(), 'pacts'), spec: 2, cors: true, pactfileWriteMode: 'merge', consumer: 'Rhapsody', provider: 'Scintillas', logLevel: 'error', }), } ```

Looks like is working now, I?ll try to replace `superagent` with `fetch`

:thumbsup:

Good evening again. Do you mind clarifying this(?): >Each test is fully self-contained, with its own mock server on its own port for ?test? it means test suit I guess. I?m trying to start those 2 providers in parallel ``` global.pactProviders = { scintillas: new Pact({ port: 8000 + Number(process.env.JEST_WORKER_ID), log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'), dir: path.resolve(process.cwd(), 'pacts'), spec: 2, cors: true, pactfileWriteMode: 'merge', consumer: 'Rhapsody', provider: 'Scintillas', logLevel: 'error', }), emailGateway: new Pact({ port: 8000 + Number(process.env.JEST_WORKER_ID), log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'), dir: path.resolve(process.cwd(), 'pacts'), spec: 2, cors: true, pactfileWriteMode: 'merge', consumer: 'Rhapsody', provider: 'Scintillas', logLevel: 'error', }), } ``` with a ``` beforeAll(async done => { await pactProviders.scintillas/emailGateway.setup() done() }) ``` in each suit but it errors with `Port '8001'/'8002' is already in use by another process.` Working correctly if remove one provider from the global object. Thank you in advance

It can be for each test, but it normally adds extra overhead to restart the server every time

but fomr what I can see, the JEST_WORKER_ID would be the same for both mocks

hence it would have a port conflict

Shouldn?t the `JEST_WORKER_ID` increase with the test suit ran?

in fact is failing on two different ports ``` ime: 1s, estimated 4s FAIL test/pact/consumer/email_gateway.test.js0-19T01:07:30.248Z] INFO: pact@7.0.1/96160 on Marcos-MacBook-Pro.local: ? Test suite failed to run Port '8001' is already in use by another process. 16 | logLevel: 'error', 17 | }), > 18 | emailGateway: new Pact({ | ^ 19 | port: 8000 + Number(process.env.JEST_WORKER_ID), 20 | log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'), 21 | dir: path.resolve(process.cwd(), 'pacts'), at Pact.Object.<anonymous>.Pact.createServer (../../node_modules/@pact-foundation/pact-node/src/pact.ts:48:10) at new Pact (../../node_modules/@pact-foundation/src/pact.ts:64:34) at Object.<anonymous> (testSetup.js:18:17) FAIL test/pact/consumer/scintillas.test.js ? Test suite failed to run Port '8002' is already in use by another process. 16 | logLevel: 'error', 17 | }), > 18 | emailGateway: new Pact({ | ^ 19 | port: 8000 + Number(process.env.JEST_WORKER_ID), 20 | log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'), 21 | dir: path.resolve(process.cwd(), 'pacts'), at Pact.Object.<anonymous>.Pact.createServer (../../node_modules/@pact-foundation/pact-node/src/pact.ts:48:10) at new Pact (../../node_modules/@pact-foundation/src/pact.ts:64:34) at Object.<anonymous> (testSetup.js:18:17) Test Suites: 2 failed, 2 total Tests: 0 total Snapshots: 0 total Time: 2.156s, estimated 4s Ran all test suites matching /test\/pact\/consumer/i ```

I believe the problem could be in the `beforeAll`: before running the 1st test it starts 8001. Because the suit haven?t started yet and the ?reserved the worker 1? it tries to start a new provider again on 8001.

Have you seen the Jest example in the pact-js repo?

yes, but in that example there is a single provider

yes, but it is used across two separate test suites

in your case above, technically it _is_ just a single provider ?Scintillas?

You?re just creating two instances of it

In any case, I think you?re right about the logic.

Hi Matt, this what I?m trying to avoid. If I?m not wrong the example should be run with `--runInBand`

true, yes

I?m trying to start in parallel two different providers

np

(just wanted to make sure you had good reasons and had thought about it first :slightly_smiling_face: )

I think you?re right though, it?s probably a logic thing where the provider is being created too many times

I need, in someway, to bind the the second provider to the starting on the first test suit

or I could scope the `beforeAll` inside each test suit, making sure to start only when the previous is started

why not just a) hard code the port for each test suite or b) randomly generate the port for each test suite?

`s/test/test suite`

well, hard coding the ports, brought up something new. ``` Setting up Pact with Consumer "Rhapsody" and Provider "Scintillas" using mock service on Port: "8001" [2018-10-19T02:16:38.270Z] INFO: pact@7.0.1/1710 on Marcos-MacBook-Pro.local: Setting up Pact with Consumer "Rhapsody" and Provider "Scintillas" using mock service on Port: "8002" ```

do you see anything wrong with this global object pattern? ``` global.pactProviders = { scintillas: new Pact({ port: 8001, log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'), dir: path.resolve(process.cwd(), 'pacts'), spec: 2, cors: true, pactfileWriteMode: 'merge', consumer: 'Rhapsody', provider: 'Scintillas', logLevel: 'error', }), emailGateway: new Pact({ port: 8002, log: path.resolve(process.cwd(), 'logs', 'mockserver-integration.log'), dir: path.resolve(process.cwd(), 'pacts'), spec: 2, cors: true, pactfileWriteMode: 'merge', consumer: 'Rhapsody', provider: 'Scintillas', logLevel: 'error', }), } ```

seems to work fine when hard coding?

could it be at jest uses parallel test runners?

I'm not entirely versed in how jest works

looks OK to me

sometimes javascript is frustrating ``` Test Suites: 0 of 2 total Tests: 0 total Snapshots: 0 total Time: 1s[2018-10-19T02:36:27.226Z] INFO: pact@7.0.1/5567 on Marcos-MacBook-Pro.local: Setting up Pact with Consumer "Rhapsody" and Provider "Scintillas" using mock service on Port: "8001" [2018-10-19T02:36:27.228Z] INFO: pact@7.0.1/5567 on Marcos-MacBook-Pro.local: Setting up Pact with Consumer "Rhapsody" and Provider "Scintillas" using mock service on Port: "8002" [2018-10-19T02:36:27.273Z] INFO: pact@7.0.1/5568 on Marcos-MacBook-Pro.local: Setting up Pact with Consumer "Rhapsody" and Provider "Scintillas" RUNS test/pact/consumer/scintillas.test.js RUNS test/pact/consumer/email_gateway.test.js Test Suites: 0 of 2 total Tests: 0 total Snapshots: 0 total Time: 2s[2018-10-19T02:36:27.933Z] ERROR: pact-node@6.19.11/5568 on Marcos-MacBook-Pro.local: Pact Binary Error: /Users/marcodellolio/src/rhapsody/node_modules/@pact-foundation/pact-node/standalone/darwin-1.54.4/lib/vendor/ruby/2.2.0/gems/webrick-1.3.1/lib/webrick/utils.rb:85:in `initialize': Address already in use - bind(2) for "127.0.0.1" port 8001 (Errno::EADDRINUSE) from /Users/marcodellolio/src/rhapsody/node_modules/@pact-foundation/pact-node/standalone/darwin-1.54.4/lib/vendor/ruby/2.2.0/gems/webrick-1.3.1/lib/webrick/utils.rb:85:in `new' from /Users/marcodellolio/src/rhapsody/node_modules/@pact-foundation/pact-node/standalone/darwin-1.54.4/lib/vendor/ruby/2.2.0/gems/webrick-1.3.1/lib/webrick/utils.rb:85:in `block in create_listeners' from /Users/marcodellolio/src/rhapsody/node_modules/@pact-foundation/pact-node/standalone/darwin-1.54.4/lib/vendor/ruby/2.2.0/gems/webrick-1.3.1/lib/webrick/utils.rb:82:in `each' ```

now fails on the same port

I don't see a failure?

sorry I should have it past it all

right, I believe it's because that jest try to run all tests in parallel

hence, there will be a port conflict

unless, there's an individual pact server ran on a random port

for each test

I?m trying to achieve parallelism. For what concerns the server setup I?m just using the following ``` beforeAll(done => { Promise.all( Object.keys(pactProviders).map(provider => pactProviders[provider].setup()) ).then(() => done()) }) afterAll(done => { Promise.all( Object.keys(pactProviders).map(provider => pactProviders[provider].finalize() ) ).then(() => done()) }) ```

instead of using beforeAll/afterAll

why don't you just use a single before/after?

which will run before and after each individual tests?

I should set a specific before hook for each test suit?

I think so, if you want to go the parallel route :slightly_smiling_face:

let me try this path and I?ll let you know. Thank you guys!

:thumbsup:

Btw, we're aware that this is a frustrating issue (especially with Jest), and @schalkt worked on a proposal for a better DSL: https://github.com/pact-foundation/pact-js/issues/215

so, I was able to run the test in parallel defining the provider inside the test suit. Thank you all as always and good night

Where are you, Marco? It's only 14:34 here :sweat_smile:

Atlanta, US. Its 23:35 here!

Where are you all?

Many of us are in Melbourne, Australia~* :flag-au:

:arrow_up:

Haha, many are in other places, too :stuck_out_tongue:

@matt.fellows (and other interested parties) - I'm thinking of closing all of those dependabot pull requests

Many of them introduce breaking changes, and for the ones that don't, I'm not sure we should be upgrading libraries without a reason

Thoughts?

yep, go for it. There?s that branch for pact-js that we?ll fix manually to begin with, at which point we can re-enable it

lol, looks like Github's coming back online

@simon.nizov has left the channel

Hey Guys good morning (I guess good evening in AU:flag-au:). Thank you for your help with jest, everything is running smoothly! I have a question about Karma

I define my pact server in `karma.conf.js` and in the test file I create a new provider. ``` provider = new Pact.PactWeb({ consumer: 'Rhapsody', provider: 'Scintillas', port: 9443, host: '127.0.0.1', }) ``` What if in my `karma.conf.js` I define more servers, how do I create a mock provider identifying the right server? Just the port?

has joined #pact-js

@marco.dellolio yes, we use it like that. The only difference is the port (and potentially the provider name)

@marco.dellolio, as @tom.hombergs said. You also don?t even need to pass the consumer/provider to the `PactWeb` constructor anymore (no need to duplicate what?s configured in the karma conf anyway). There should be a warning in your console about that I think

Thank you guys. Yes I was able to dry up my code a little

:+1:

Hello guys, does anybody have a good use case of Pact working with `$httpBackend` in Angular.js sounds like it prevents to make real http request in the test environment

https://github.com/DiUS/pact-consumer-js-dsl/wiki/Using-Pact-with-Angular ?

That?s a pretty old repo, but the idea is probably the same - you?ll need to ensure there is a real http service injected into your configuration

I haven?t used Angular for a few years, and am out of touch with current practices myself

For me is brand new, we have a good part of our legacy front end with Angular models serving data to React Components, need to cover those with Pact as well

@matt.fellows thanks for looking into https://github.com/pact-foundation/pact-js/issues/234 for me! What's the difference between the @pact-foundation/pact-web and @pact-foundation/pact packages anyways?

No worries @tom.hombergs. I don?t have time for the longer version, but the TL;DR is https://github.com/pact-foundation/pact-js/#using-pact-in-non-node-environments

new project, who dis? ``` .../node_modules/@pact-foundation/pact/pact.js:40 this.opts = Pact.createOptionsWithDefaults(config); ^ TypeError: Cannot set property 'opts' of undefined ```

Anyone seen this coming from the `Pact({...})` provider constructor?

Working from https://github.com/pact-foundation/pact-js/blob/master/examples/mocha/test/get-dogs.spec.js

ahaha omg . . . missing a `new` keyword :ok_hand::innocent:

Lol

Thanks @tom.hombergs

also, in case you haven?t seen it, your eyeballs on https://github.com/pact-foundation/pact-js/issues/209 and https://github.com/pact-foundation/pact-js/issues/215 would be appreciated. Looking to simplify things whilst also making it more powerful/expressive

has joined #pact-js

has joined #pact-js

has joined #pact-js

has joined #pact-js

has joined #pact-js

has joined #pact-js

yay

mostly passed :slightly_smiling_face:

has joined #pact-js

has joined #pact-js

Hi everyone. Is the intention of the function in this example https://github.com/pact-foundation/pact-js/blob/d8214e6112f3ba26b93f46bee7fa6f3d8d970f76/karma/jasmine/client.js#L8 to show that we need to implement a method in each service we test with pact to override the environment's api base url? Thanks for any advice you can give

The below code passes when calling `apiService.createPactClient`. I'd prefer not to have to create a new method in this service just to set localhost as the base url instead of the environment's api base url. However if I try to hardcode the base url + my path in the `karma.conf.js` as proxy key, it can't see the request. Am I doing something wrong? Using Angular 6 + Karma + Jasmine ``` // karma.conf.js module.exports = function (config) { ... pact: [{ consumer: 'ApiService', provider: 'backend', port: 7228, logLevel: 'DEBUG', cors: true, log: path.resolve(process.cwd(), 'logs', 'pact.log'), dir: path.resolve(process.cwd(), 'pacts'), }], proxies: { '/me': 'http://127.0.0.1:7228/me', }, } ``` ``` // api.service.js import environment from './environment'; // simplified from a Typescript + Angular 6 class class ApiService { // Overwrite the environment base api url createPactClient(baseUrl: string) { environment.apiBaseUrl = baseUrl; } getUser() { const path = '/me'; return HttpClient.get(`${environment.apiBaseUrl}${path}`, new HttpHeaders()); } } ``` ``` // api.service.spec.js import * as Pact from '@pact-foundation/pact-web'; describe('PACT ApiService', () => { let apiService; let provider; const dummyUser = { firstName: 'dummy firstName', lastName: 'dummy lastName', }; beforeAll(done => { provider = new Pact.PactWeb({ port: 7228, host: '127.0.0.1', }); done(); provider.removeInteractions(); // Required for `singleRun: false` }); afterAll(done => { provider.finalize().then(done, e => done.fail(e)); }); beforeEach(() => { TestBed.configureTestingModule({ imports: [HttpClientModule], providers: [ApiService], }); apiService = TestBed.get(ApiService); }); describe('getUser', () => { beforeAll(done => { provider.addInteraction({ state: 'provider responds with a user', uponReceiving: 'a request to GET a user', withRequest: { method: 'GET', path: `/me`, }, willRespondWith: { status: 200, body: Pact.Matchers.somethingLike(dummyUser), }, }).then(done, e => done.fail(e)); }); afterEach(done => { provider.verify().then(done, e => done.fail(e)); }); it('should get user', done => { // Overwrite the environment api base url apiService.createPactClient('http://localhost:7228'); apiService.getUser().subscribe(response => { expect(response).toEqual(dummyUser); done(); }, e => done.fail(e)); }); }); }); ```

Pretty much, yes. Another standard option is to use Environment variables to inject configuration (in non-Karma use cases probably)

I?m not that familiar with `proxies` in Karma/Angular. Is it possible to have another `environment` configuration for `pact` tests, which contains the endpoint/port required for pact tests? This way it?s consistent with the rest of your code base?

Thanks I will try to set up another environment for pact, but instead I think it would be for karma as that is what I use to run pact along with my other tests. Perhaps having them run independently makes more sense. I'll work out how to set the environment variable for the base url to localhost when running in karma + pact

has joined #pact-js

Hey everyone. I was wondering if people have had experience using this in integration between frontend and backend (for example a React app and a NodeJS backend)? The reason I'm asking is because I am now working on establishing it between frontend and backend (where I see it can definitely bring a lot of value), but I feel like the "Consumer Driven" part gets a bit lost in some parts, depending on how you do it. I saw a couple of examples of people trying it online, and I guess that's what I want to know - what you think is the best approach: - Approach A: you write your consumer tests on the http client or functions dealing with making the requests, and you just concern yourself with the data being handled properly by the HTTP client; - Approach B: you write actual frontend facing consumer tests on how this data is handled by the UI; So, Approach A is simple to implement and still guarantees that when the provider API makes changes, it doesn't break the frontend (the more common use-case). But Approach B is more "consumer driven" , because if you were to make changes to how you handle or expect the data, it would actually break a consumer build. Which one is best? Is there value in both?

@bernardo.guerreiro happy you?re bringing up the subject. A sounds more like by-the-book consumer unit testing. B you can still do but in a form of end-to-end integration tests. Meaning that with B you are actually clicking buttons on the UI and driving flows that trigger API calls, which you can then have a stubbed mock server based on the consumer contracts, to return the results for.

I think b, but not in the form that tests via a UI e2e test. You want to test your service delegate code / collaborator. If it still feels closer to a pure unit test then you're in the sweet spot

Most examples use the http client for convenience/ simplicity

See js issues - one is there about expired being contrived

Hey Guys , I am writing a provider verification tests and verification is failing due to difference in actual and expected .I am trying to add matchers and see if it works .I am using method verifyProvider and for that i was used the parameter pactBrokerUrl .I want to know is it possible to verify the provider with my local json file and if yes , how ?

@dagarwal sure, you can `pactUrls` instead of `pactBrokerUrl` and include contract files from the local filesystem. an example from the docs: ```js pactUrls: [path.resolve(process.cwd(), "pacts", "myjsmessageconsumer-myjsmessageprovider.json")], ```

Wow cool thanks :slightly_smiling_face:

:+1:

~I am gettign * Expected 8061159 but got 15053699 at $[0].id * Expected ?Country? but got ?address? at $[0].name * Expected ?Country? but got ?Address? at $[0].displayName * Actual array is too short and should have contained 10329 at $[0].visibilityIds[1] * Actual array is too short and should have contained 10323 at $[0].visibilityIds[2] * Actual array is too short and should have contained 10240 at $[0].visibilityIds[3] * Actual array is too short and should have contained 17575 at $[0].visibilityIds[4] * Expected ?31 Jan 2018 11:56:48 +00:00? but got ?10 Jul 2018 11:04:50 +00:00" at $[0].created * Expected ?01 Feb 2018 11:58:49 +00:00? but got ?10 Jul 2018 11:04:50 +00:00" at $[0].lastModified * Expected 8078165 but got 15053796 at $[1].id * Expected ?demo-tt? but got ?asdf? at $[1].name * Expected ?Demo tt? but got ?asdf? at $[1].displayName * Expected ?01 Feb 2018 11:03:59 +00:00? but got ?10 Jul 2018 11:21:20 +00:00" at $[1].created * Expected ?01 Feb 2018 11:03:59 +00:00? but got ?10 Jul 2018 11:21:20 +00:00" at $[1].lastModified * Actual array is too long and should not contain a Hash at $[2] * Actual array is too long and should not contain a Hash at $[3] * Actual array is too long and should not contain a Hash at $[4] * Actual array is too long and should not contain a Hash at $[5] * Actual array is too long and should not contain a Hash at $[6] * Actual array is too long and should not contain a Hash at $[7] and so on when i am doing provider verification~

I am getting * Expected 8061159 but got 15053699 at $[0].id * Expected ?Country? but got ?address? at $[0].name * Expected ?Country? but got ?Address? at $[0].displayName * Actual array is too short and should have contained 10329 at $[0].visibilityIds[1] * Actual array is too short and should have contained 10323 at $[0].visibilityIds[2] * Actual array is too short and should have contained 10240 at $[0].visibilityIds[3] * Actual array is too short and should have contained 17575 at $[0].visibilityIds[4] * Expected ?31 Jan 2018 11:56:48 +00:00? but got ?10 Jul 2018 11:04:50 +00:00" at $[0].created * Expected ?01 Feb 2018 11:58:49 +00:00? but got ?10 Jul 2018 11:04:50 +00:00" at $[0].lastModified * Expected 8078165 but got 15053796 at $[1].id * Expected ?demo-tt? but got ?asdf? at $[1].name * Expected ?Demo tt? but got ?asdf? at $[1].displayName * Expected ?01 Feb 2018 11:03:59 +00:00? but got ?10 Jul 2018 11:21:20 +00:00" at $[1].created * Expected ?01 Feb 2018 11:03:59 +00:00? but got ?10 Jul 2018 11:21:20 +00:00" at $[1].lastModified * Actual array is too long and should not contain a Hash at $[2] * Actual array is too long and should not contain a Hash at $[3] * Actual array is too long and should not contain a Hash at $[4] * Actual array is too long and should not contain a Hash at $[5] * Actual array is too long and should not contain a Hash at $[6] * Actual array is too long and should not contain a Hash at $[7] and so on when i am doing provider verification.Even if i add PACT.like it starts to give ?visibilityIds?: [ ... , - Fixnum, - Fixnum, - Fixnum, - Fixnum, + Pact::IndexNotFound, + Pact::IndexNotFound, + Pact::IndexNotFound, + Pact::IndexNotFound, ] }, ... , - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex, - Pact::UnexpectedIndex,

Can someone help me with what kind of matchers needs to be added

has joined #pact-js

What have you tried? Can you please share? Looks like you need an `eachLike`

i tried like

will try with each like .Basically provider have big array list like { (arr1,val1), (arr2,val2) , (arr3,val3) and so on and I have added just two values {(arrConsumer1,valConsumer1) ,(arrConsumer2,valConsumer2) )

Also values are different

Hi , I am getting this error after adding matchers : like while doing verification . 1) Verifying a pact between flex-search-app and flex-taxonomy-service Get object for listing taxonomies with GET /api/taxonomies?accountId=4&enabled=true returns a response which has a matching body Failure/Error: expect(response_body).to match_term expected_response_body, diff_options, example [2018-11-27T10:14:07.150Z] WARN: pact-node@6.20.0/41092 on Dollys-MacBook-Pro.local: Pact exited with code 1. Actual: [{?id?:15053699,?name?:?address?,?displayName?:?Address?,?description?:??,?enabled?:true,?accountId?:4,?visibilityIds?:[4],?userId?:5,?created?:?10 Jul 2018 11:04:50 +00:00?,?lastModified?:?10 Jul 2018 11:04:50 +00:00?},{?id?:15053796,?name?:?asdf?,?displayName?:?asdf?,?description?:??,?enabled?:true,?accountId?:4,?visibilityIds?:[4],?userId?:5,?created?:?10 Jul 2018 11:21:20 +00:00",?lastModified?:?10 Jul 2018 11:21:20 +00:00"}, and so on Its a huge array list at provider level . At At consumer level i have added the test as : before(() => { return provider.addInteraction({ given: ?GET call for taxonomies?, uponReceiving: ?Get object for listing taxonomies?, withRequest: { method: ?GET?, path: ?/api/taxonomies?, query: { accountId: term({ generate: ?4?, matcher: ?4? }), enabled: term({ generate: ?true?, matcher: ?true? }) } }, willRespondWith: { status: 200, body: [ like ({ ?id?: like(8061159), ?name?: like(?Country?), ?displayName?: like(?Country?), ?description?: like(??), ?enabled?: like(true), ?accountId?: like(4), ?visibilityIds?: like([ 4, 10329, 10323, 10240, 17575 ]), ?userId?: like(5), ?created?: like(?31 Jan 2018 11:56:48 +00:00?), ?lastModified?: like(?01 Feb 2018 11:58:49 +00:00?) }) ] } }); });

@dagarwal it?s really hard to help with partial output. if you don?t have the code publicly available to look at, can you paste the full output of the pact test failure on some place like pastebin and provide a link?

Ok sure would do that

@liran.tal https://pastebin.com/eCvwM0aM

https://pastebin.com/eCvwM0aM and

I can point out several things that look a bit off. on the consumer side - 1. the term matchers on the query doesn?t look like they?re used properly. the matcher is supposed to be a regex syntax 2. the matching for dates is not going to really work the way you think, it?ll just match any string type, not the actual date format you see there now. 3. the visibility ids are using hard coded items

cool , let me try updating these and see if it works Thanks !!

I suggest that you try to build the contract and verify it step-by-step. it will be easier for you to debug what?s wrong and why it fails

if you add many matchers and expectations on the consumer side and something fails on the provider, it?s hard to debug why exactly.

I mean, the log is there to help you but if you?re starting out fresh you might want to take it in steps

Actually we built in huge tests at consumer level and data has got complex .now we are doing provider verification :disappointed: should have done it from initial stage .I am really struggling now

I can see the problem

when using array matchers, you need to remove the actual array within/ouotside

e.g.

`body: eachLike({?})` not `body: [ like({...}) ]`

or `body: eachLike({?})` not `body: eachLike([{...}])`

`eachLike` implies it?s an array

so pact is expecting an array containing an array

I?ve answered your question on SO also

Thanks a lot :dancer: it worked

Hi, Are there are any recommended ways to automate pact test creation (in my case for an Angular 7 webapp)? Preferably generating tests off an (api) service

No - see https://docs.pact.io/faq#can-i-generate-my-pact-file-from-something-like-swagger

Thanks. We have an api service which is rapidly expanding and are looking for a sustainable way to expand our pact tests without copy and pasting chunks of `describe('...` Really trying to decide where the source of truth is, and how to minimise mistakes in the pact tests

gotcha

great!

Don?t forget to accept the answer :wink:

The key thing is that each test needs to capture the intentions of the consumer, not what is documented in a provider.

It might be possible to automate it, but you?re likely to add in assumptions that your client code is doing that may be incorrect and therefore void all of the pact work

Understood. Thanks. I think we won't be automating this now.

@dagarwal can you please share what you expect your API response to look like to help you with your matchers?

I suspect you want an object which contains array items (taxon's), not an array of items which always have arrays nested within

This is why it's telling you it's expecting an array, but got a hash

The eachLike matcher says at the location specified, it expects an array

has joined #pact-js

@matt.fellows Yes exactly . It contains array items in taxons . Please find link : https://pastebin.com/2SJnTrfG

So if the root reflect is not an array, reminder the eachlike matcher on it, but leave it for taxons

has joined #pact-js

reminder the eachlike matcher on it, means .I dint get it :disappointed:

I?ve updated the example in SO. I think you want this: ``` const firstChild = like({ ?name?: ?Geo?, ?taxons?: eachLike({ ?id?: 115590, ?name?: ?Africa?, ?hasChildren?: false }) }); `` Note that the initial `eachLike` is now just `like`. This means you don?t expect an array at the root of the response, you want an object.

~hey pact people, has anyone got an example of updating the provider on a test by test basis for jest? my consumer has contracts with multiple providers so I need to update the provider on a test by test basis to create multiple pacts. I don't think I've seen an example of doing this in JS - i might have missed it. any pointers gratefully received!~

Thanks @matt.fellows :slightly_smiling_face:

i want to use more than one element in array. I am using eachLike with min .Can you guys tell me whats wrong here : const taxonomiesList = [{ ?id?: 8061159, ?name?: ?Country?, ?displayName?: ?Country?, ?description?: ??, ?enabled?: true, ?accountId?: 4, ?visibilityIds?: like[4], ?userId?: 5, ?created?: ?31 Jan 2018 11:56:48 +00:00?, ?lastModified?: ?01 Feb 2018 11:58:49 +00:00? }, { ?id?: 8078165, ?name?: ?demo-tt?, ?displayName?: ?Demo tt?, ?description?: ??, ?enabled?: true, ?accountId?: 4, ?visibilityIds?: like[4], ?userId?: 5, ?created?: ?01 Feb 2018 11:03:59 +00:00?, ?lastModified?: ?01 Feb 2018 11:03:59 +00:00? ]) const taxonomies = eachLike(taxonomiesList, { min: 2}); module.exports = { taxonomies }; But this is generating both id ( inside body ) two times ( so total 4) in the json file

All good. Did that help you understand how it works?

has joined #pact-js

yes but still I am unable to create data for more than one element in array using eachLike and min

If you need further help, we'll need a code base where we can reproduce the problem your having exactly

Okay

Thanks

@dagarwal I?ve mentioned this a few times - _do not_ put an array `[]` inside of the `eachLike` statement for what you are trying to do to. It is trying to create a multi-dimensional array. You want a single dimension array, so simply put _one_ object inside the `eachLike` clause e.g. ``` eachLike({ 'id': 8061159, 'name': 'Country', 'displayName': 'Country', 'description': '', 'enabled': true, 'accountId': 4, 'visibilityIds': like[4], 'userId': 5, 'created': '31 Jan 2018 11:56:48 +00:00', 'lastModified': '01 Feb 2018 11:58:49 +00:00' }) ```

Hi Matt and all, Could you explain this setTimeout to me please? https://github.com/pact-foundation/pact-js/blob/master/karma/jasmine/client-spec.js#L16 I had intermittently failing tests yesterday (only in our CI build - in docker on VSTS, and very occasionally locally) and putting `done()` into the setTimeout in that beforeAll for each test fixed it. Still can?t work out which interaction clearing this is delaying. Is this preventing tests from clearing each other?s interactions? Or is it preventing one of the below lines from clearing the test?s own interactions before the request is received? `provider.removeInteractions();` `provider.finalize().then(done, e => done.fail(e));` `provider.verify().then(done, e => done.fail(e));` In this failing test we can see the interaction was registered, then cleared and then request was received (so no request was found). ``` I, [2018-12-11T16:32:35.619070 #5595] INFO -- : Registered expected interaction GET /my/stuff D, [2018-12-11T16:32:35.619242 #5595] DEBUG -- : { "description": "a request to GET stuff", "providerState": "provider responds with snapshot ref data", "request": { "method": "GET", "path": "/my/stuff" }, "response": { "status": 200, "headers": { "Content-Type": "application/json" }, "body": { "json_class": "Pact::SomethingLike", "contents": { "0": { "stuff": "dummy stuff", } } } } } I, [2018-12-11T16:32:35.620329 #5595] INFO -- : Cleared interactions I, [2018-12-11T16:32:35.653797 #5595] INFO -- : Received request GET /my/stuff ```

? then this line triggers the fail ``` E, [2018-12-11T16:32:35.653947 #5595] ERROR -- : No matching interaction found for GET /my/rates-evidence ```

yes @matt.fellows thanks

It's a bit of a hack. Its basically saying "wait for 2 seconds and hope the pact mock server is up in time on port 1234

A better way would be to wait for the port to be ready

Is this test failing or one of yours? If you share the code I'm happy to take a look

I had random failures on my CI build only across all tests until I put the done in a setTimeout. All tests are consistently passing now, but adds +2s for each test. What I?m trying to understand is which line is doing the ?Cleared interactions? in between registering interaction and receiving request. From looking at pact-web.js, could be one of three provider methods (mentioned above). Line 28, 32 or 70 in below gist. Here?s the gist, thanks :slightly_smiling_face: https://gist.github.com/rorymcgit/819f1a3eb697c864fcf47c9e6f8f5fe2

removeInteractions, finalise and verify will all clear them from memory

Do you know which one of these is causing the ?Cleared interactions? in this case, i.e. if the `done()` on line 25 is not in a setTimeout?

hmm not at a cursory glance i?m sorry. If you had your code to share i?m haappy to look at that too

I have the gist here, thanks https://gist.github.com/rorymcgit/819f1a3eb697c864fcf47c9e6f8f5fe2

Hmm the provider removeInteractions in the before all is a promise. Stricly speaking you might want to properly handle it even tho the setTimeout above should prevent it.

Are there any strange Jasmine overlapping behaviours causing strangeness?

I found that everything ran in the order it should have run (by putting a load of numbered console.logs throughout the code), even for failing tests. That?s interesting that `removeInteractions` isn?t really being handled properly. I might try moving the done from inside the setTimeout to in a `.then`. Thanks for your help - I?ll update you if I find anything interesting

@matt.fellows I said I?d update if I found anything interesting, and I think I have. https://gist.github.com/rorymcgit/cf7cc8f07c20507f699900f8484435c1#file-api-service-get-foo-pact_v2-spec-ts-L23 Moving the `done()` to happen on resolve of the `removeInteractions` means my CI build does not have pact tests failing intermittently (like it was without being wrapped by the setTimeout) and does not add 2 seconds per test either.

Thanks @rjmcguinness - makes sense!

has joined #pact-js

Hello , Do we have any npm package to install can-i-deploy ?

Sorry, I haven't gotten around to enabling that in pact-node yet :confused:

@mboudreau Ok thanks .It would be good to have it

One more question so to implement in this jenkins , i need to run the command to install it .any other way ? @mboudreau

Well, when you use npm, it does install the Ruby binary, so you could hit it directly with the command. There's already a pull request for this change, I just need to spend some time to add it. Could you allow me a day to look the pr over and merge it and release a new version?

wow that would be great , Sure .Please let me know when done :slightly_smiling_face:

has joined #pact-js

Also if you haven't seen this, take a look

Examples of using the binaries from package.json

Once properly installed into the path it should he even easier

@dagarwal I've updated pact-node to include `can-i-deploy`, version 6.21.0

:clap:

wow thanks @mboudreau :slightly_smiling_face:

Thanks Matt its good , i havent checked that link before

@mboudreau Latest version for that is 6.20.2 as of now

from where? npm says 6.21.0 https://www.npmjs.com/package/@pact-foundation/pact-node

It gave me this ? Please choose a version of ?@pact-foundation/pact-node? from this list: (Use arrow keys) ? 6.20.2 6.20.1 6.20.0 6.19.12

just update your package.json file to use 6.21.0 and do an `npm install`

yeah it worked with that .I updated package and file and was doing yarn install and getting error

Thanks

must have been some caching or something

yeah right

great work @mboudreau , I use pact-node and we were previously using the can-i-deploy standalone, so nice to have this option now :ok_hand:

thanks :slightly_smiling_face:

it was mostly @tjones doing the work, I just supervised :stuck_out_tongue:

Thanks to @tjones too for the efforts :slightly_smiling_face:

Hello @mboudreau @tjones thanks for can-i-deploy functionality .but it fails when we do can i deploy because in can-deploy.js file this.__argMapping , we are passing ?version?: ?--version?, but in the function we are using options.pacticipantVersion =options.pacticipantVersion instead of options.pacticipantVersion =options.version .I tried replacing the variables and it works fine .Please fix it . Do let me know if you want any further information .Thanks

crap, sorry, you're right

np .Please let me know once the update is ready :slightly_smiling_face:

I'll do it now

Perfect

6.21.1 is building now, should be available in about 10 minutes

Did this version work @dagarwal?

has joined #pact-js

no @mboudreau it is giving me same error

has joined #pact-js

could you Please check @mboudreau

whoops, didn't see this

I'll get it done now

Okay thanks

wait, how are you calling can-i-deploy? can you give me an example of the command you use?

yes I am doing like this

const pactNode = require('@pact-foundation/pact-node'); const checkVerificationForProvider = { pacticipant: [Pacticpant1], version: ['1.0.0'], pactBroker: 'https://pact.ooflex.net/' }; pactNode.canDeploy(checkVerificationForProvider).then(() => { console.log("Verified can i deploy against Provider?); }).catch(err => { console.error("Verification failed for can i deploy Provider service", err); });

can you change "version" for "pacticipantVersion" as see if it works?

ok let me try

The version must be specified using --version or --latest [TAG] for pacticipant flex-taxonomy-service Verification failed for can i deploy against flex taxonomy service Error: The version must be specified using --version or --latest

i get this @mboudreau

ah, yeah, I see it now

i guess here we need to pass version only as in the internal code you are using it as pacticipactVersion

the pact binary uses --version but I can't with the CLI in node since it messes up the CLI and thing --version is for the project version

hence why I'm trying to use pacticipantVersion since it's also more descriptive

okay so will you be changing the code accordingly ?

yep, gimme a moment

Sure ,thanks

there's some tests missing here to make sure this doesn't break again. I'm going to release a quick fix for now, but I'll need to invest more time in the tests so that it won't ever break again :slightly_smiling_face:

Sounds good :slightly_smiling_face:

you going to be around in the next 10 minutes to make sure it works?

Okay

cool, sending it off for deployment, I'll let you know when it's up so you can confirm it works on your end and finish this for good :slightly_smiling_face:

sure

6.21.2 is out, please try it now :slightly_smiling_face:

@dagarwal?

yes trying

it works :slightly_smiling_face: thanks @mboudreau

woo!

np, thanks for being patient :slightly_smiling_face:

Hi Matt and all, Using Karma/Jasmine/Angular 7/Typescript with karma-pact, pact-node, pact-web. I have added the eachLike matcher to my tests but have run into a problem with my Jasmine text expectations. The Jasmine test is failing here https://gist.github.com/rorymcgit/7858c2e82f4d70341072d981dc70b54b#file-failing-eachlike-api-service-get-foo-pact-spec-ts-L62 because I have changed the body of the object to include the eachLike matcher. Previously in my `provider.addInteraction` I had: ``` willRespondWith: { status: 200, body: Matchers.somethingLike({ foo: [{ bar: ['a string'], }, { bar: ['another string'], }], }), } ``` Which meant I could `expect(response).toEqual(sameObjectAsWasPassedToBody)`. The only difference being wrapping it in a `somethingLike` above. Now I have: ``` willRespondWith: { status: 200, body: { foo: Matchers.eachLike({ bar: ['a string'], }), }, } ``` So I have to assert that the response is equal to a different object than what I have assigned to the `body` in the interaction. https://gist.github.com/rorymcgit/0bb82714b2de91fde8769b4acd668c2f#file-passing-eachlike-api-service-get-foo-pact-spec-ts-L68 My question is: What is the value of a Jasmine test in our Pact test, if all we are testing anyway is what has been passed into the `body`? We are not testing api method (as it is stubbed by the Pact provider service). The value of Pact from a consumer side is to generate the Pact and test our requests.

I am tempted to remove the expectation and just `provider.verify()`

The point of `expect` in a pact test like this is to be able to ensure that the correct domain object is returning to the caller of `getFoo()`. In Javascript, that is often (but not always) the same object that's on the wire

if you're just returning the wire object without transformation, you could safely remove the expectation in your test

However, what I like to do instead is to have a file of fixtures that describe the domain objects. This file is shared between the pact test's `expect` line, and the tests for the call site of `getFoo()`.

This means that we can be sure that the callers of `getFoo()` and the pact between your foo client and provider are in sync

With typescript, you probably don't need to do this

without that `expect` call, you're missing out on: 1) Does the api method return the object? (guarding against misuse of the response in your `getFoo()`, eg returning `response` instead of `response.body`) With shared fixtures, or careful typescript types, you also get: 2) Does the api method return the same object that the caller expects?

:point_up: this

Thanks for this, that?s very clear. I?ll keep the expectation and find a way to share the objects. Do you have any thoughts on programatically adding `eachLike`s? i.e. adding a test helper method that iterates over the object and replaces arrays with `eachLike(array[0])`.

has joined #pact-js

Have anyone done this before?

See https://docs.pact.io/faq#why-is-there-no-support-for-specifying-optional-attributes

I personally wouldn't do that, because the domain object (returned by the call site of your API) is a different object conceptually to the wire object (tested by pact verification), so I prefer them to be separate objects in code, even if they're very similar/the same. However, I don't think it's wrong to try it - If you prefer no duplication, then a helper like you suggest seems like the way to go. I'd be interested to know how you like it after a few months of use.

has joined #pact-js

Hello,

can someone help me understand how the pact term works?

i currently have a few done on my poc but when verifying i have no match done

mocha is complaining about it

what have you tried so far?

It?s a regex matcher, which must correspond to the Ruby regex format. There are examples in the repo worth looking at first

Why would mocha care about the matcher? can you please elaborate?

so I am validation iso8601DateTime

the default regex available on the DSL works when using a web based validator

but not when I do it on the pact

the generate is being hard matched with the expected response

I haven?t done the provider side yet I am starting at the consumer

for example: ``` state: term({ matcher: 'ReviewPending|Approved|FundsPosted|SentToBank|Completed|RejectedFundsNotPosted|RejectedFundsNotSentToBank|RejectedUnapproved|RejectedValidationFailed|SendToBankFailed|FundsReturned|Postponed|Canceled', generate: 'Postponed', }),```

the response from the provider will include any of those states

``` transferTime: like('2018-12-18T21:21:28.619Z'), ```

or different timestamps

What do you mean hard matched on the response? This doesn't make sense if your doing a consumer test.

Are you matching a response or a request?

Which one isn't working? The time or the other?

``` interaction = { state: 'I have a list of transfer', uponReceiving: 'a request for all transfers', withRequest: { method: 'GET', query: 'page_size=5000', path: '/', }, willRespondWith: { status: 200, headers: { 'Content-Type': 'application/json' }, body: noFilter, } };``` `noFilter` has the Matchers ``` it('returns the correct response', async() => { await searchRequest().then((response) => { expect(response).to.eql(SEARCH_RESPONSE); }) });``` `SEARCH_RESPONSE` has a static JSON at the moment

What are you expecting to happen here? I expect `response` to have the values `2018-12-18T21:21:28.619Z` and `Postponed` in it

What?s the actual problem?

So this is a consumer test, any `generate` value provided to the `term` matcher will be what comes back from the mock service. Later on during provider verification, it will check what the provider actually responds with, and will use the `matcher` portion of the test to ensure it is what is expected

Then why is that the SEARCH_RESPONSE (which is a copy json of the response of the provider) failing?

@vicenzo are you sure that `.to.eql` is a deep equal? I thought it was a simple reference check just like `===` which won't work since the response is not the same object as the SEARCH_RESPONSE

look to see if it has a `.to.deep.eql` instead

the assertion error message is the same

`AssertionError: expected { Object (pageCursorId, evaluatedTransfers) } to deeply equal { Object (pageCursorId, evaluatedTransfers) } <Click to see difference>`

what's the difference?

can you share the definitions of `noFilter` and `SEARCH_RESPONSE`?

let me get a gist wipped up

if it's chai, then I believe `eql` is the deep equal. `equals` is the reference check.

wait, you're calling your API to return something that's auto generated?

@vicenzo - are you hitting the pact mock server with this consumer test, or your real API?

mock server @tjones

```const provider = new Pact({ consumer: 'sentinel-ui', provider: 'sentinel-judge', host: 'localhost', port: MOCK_SERVER_PORT, log: path.resolve(process.cwd(), 'logs', 'pact.log'), dir: path.resolve(process.cwd(), 'pacts'), spec: 2, pactfileWriteMode: 'update', logLevel: 'info', });```

`searchRequest()` uses window to define the URL, I am just overriding the window global to point to the mock

You are correct on that one

why are you using term matchers for your response?

I mean, it's fine, but then you have the SEARCH_RESPONSE which is static and then completely different from your interaction

and you expect it to be the same

which I don't really understand why you're doing this in the first place

so maybe I am missing the point completely of how to write these tests

I can flip the script

would that fix it?

oh right that was why

when I use the matchers on the expect I get the pact json

before it is run through the ruby cli

well, I'm not sure why you're testing the response at all, it's kind of what pact does for you. All you want to do is make sure you test your API correctly and it's processing things correctly, and that the incoming body/query (not the response) has matchers so that the interactions are correct

so, for instance, you have a `page_size` query with 5000, maybe you want to use a term for that so that it's always a number, and it can't be lower than X or higher than Y, then have tests to make sure that these limits are working with pact and your API

I see

or that another endpoint is a post and it expects a body of type Z with property blah of type something, but the response is always going to be the same thing

this test is a bust basically because it doesn?t have the matcher on the request itself

because it is the consumer

if it was the provider than it would make sense to have the response matchers

well, I wouldn't say it's a bust, you want a test to make sure that this interaction exists and it returns something, and that your consumer can parse the response and interact with it

yes

that was the point of this particular one

but with the matchers and the like, not so much

you don't need the matchers for the response

``` willRespondWith: { status: 200, headers: { 'Content-Type': 'application/json' }, body: SEARCH_RESPONSE, } };```

so here should be like that

and the expect should be that the response.eql(SEARCH_RESPONSE)

something like that?

yes

however, making sure that response equals response is a bit redundant

maybe there's something in your consumer you want to test to make sure that this triggers and returns, then displays correctly?

the point of your consumer test is to test the consumer, including the interaction with the API

so, what's the function that calls this particular API endpoint? that's what you want to test

`searchRequest()`

this one

```export function searchRequest(params) { const query = parseSearchQueryParams(params); return requests.get(`${URL(getAppConfigSetting('apiUrl'))}?${query}`); }```

and it doesn't take any arguments or return anything?

okay, that's better

so, plenty of tests that can be done here based on the params

see if the response fails, what does it do when it fails, what does it do when it succeeds, etc

ok

I see

you can make it more complex as well if it's suppose to show something on the screen or update a state somewhere

not this one

ie. whatever in your consumer that calls `searchRequests`

could I use pact to mock the api during a ui test?

you sure can :slightly_smiling_face:

:shocked_face_with_exploding_head:

you can make it as minute as a test (unit tests, single function) or much wider and complex (e2e, ui)

with state or multiple states

right now I am just trying to get a POC done for consumer and provider

maybe I should move to the provider and see if I can break the contract

you?ll be seeing more of me soon =P

thank you for the help and lesson!

np :slightly_smiling_face:

now back to the company network where I can;t send messages

Hello guys , when i add pact matching with term here on path withRequest: { method: ?GET?, path: term({ matcher: ?/api/assets/[0-9]+?, generate: ?/api/assets/10006? }), }, ( I am getting 404 when i try to load the data on UI :disappointed: ) .Without adding matcher it just works fine for me . Any suggestions on what went wrong and how to achieve it ?

has joined #pact-js

Hey folks! Does pact-js has a full support for pact-specification v3 (https://github.com/pact-foundation/pact-specification/tree/version-3)? I'm wondering how can I specify providerStates as an array in my JS code instead of a single string.

@vitaliy.grigoruk no it doesn?t support all of v3, just the bits required to allow message pacts to work. So it?s v 2.x compatible you might say

does anything speaks against adding support for providerStates then? I may contribute with a PR.

has joined #pact-js

hey! I'm trying to validate my Pact, but my consumer uses fetch and when I run it through node that fails :confused: (fetch is not defined, etc) any pointers on how I could solve it?

You could swap out the engine for something else (e.g. super agent) during test

Another option is to use the pact-web dependency which runs in browser test environments

There are examples in the repo of karma / Jasmine tests

Or `isomorphic-fetch`?

Yep. I'd look to replace fetch as the simpler option. Pact is the easier library to deal with than pact web

awesome, thanks for the responses. I was skeptical at first thinking this would mean replacing the actual behavior of my consumer, but looks like that isn?t the case

another one: is there any matcher that would help with a return that can be a string or an object? ``` { target: "2019" } ``` or ``` { target: { value: 1000 } } ```

my first idea was to use the term regex, but I figured that won?t work for objects

p.s.: I realize that is probably not the best API design there can be, but it is what I must use :disappointed:

has joined #pact-js

There is no single matcher that would do that. You would write (at least) two separate tests to ensure that it?s covered. You may use a provider state to document in which state the provider should be in too return either of the two formats (assuming it?s a similar looking requests that produces the two different shapes)

thanks Matt, that helped :slightly_smiling_face:

has joined #pact-js

okay hopefully my last question :slightly_smiling_face: I have my pact file ready but when I try to validate it against my provider, it fails. That happens because our infra has a proxy in place that changes the endpoints of the provider. Consumer: ``` GET local/api/zoo/animals ``` Provider: ``` GET local/zoo/animals ``` How can I handle this scenario? I?ve tried changing the host to use the /api (`localhost/api`) but that made my consumer tests fail :thinking_face:

another thing to note is that the paths could be completely different depending on how it was set up (though that is less like)

Is it always consistently this new path? Or just in test or something?

yes, it is consistent. We have explicit rules to route one thing to the other, but the consumer / provider don?t know about them :confused:

How/why do the consumer tests fail? Surely it's just a config item that sets the host and context path

Sadly not a config file on either end. We have HAProxy set up doing the routing between the provider?s endpoint to something else entirely (in this case, adding /api/). The consumer (correctly) sends its requests to `/api/zoo/animals` and when the contract?s path is set to `/api/zoo/animals` the mock server is able to receive the request. With the same path, however, I?m unable to verify the provider is receiving the data from the mock server as requests are now being sent to `/api/zoo/animals` instead of `/zoo/animals` (as the provider expects). does that make sense?

Yes it does, I'm mostly confused as to how you can't modify the path the consumer uses during these tests. This is most bizarre. Can you explain why?

It's common. Some people will just test the apt with the proxy in front of it, some will remove it from the equation (there is commentary on our side Wendie about this).

> Yes it does, I?m mostly confused as to how you can?t modify the path the consumer uses during these tests. This is most bizarre. Can you explain why? I?m not sure I follow. Do you mean implement a configuration system of sorts that changes the basepath in the implementation? Or by setting the path = ?/api/?? using Pact? this is the part (I think?) I shouldn?t change or it breaks the provider: ``` // in provider.addInteractions() withRequest: { method: "GET", path: "/zoo/animals", headers: { Accept: "*/*", }, }, ```

how do we fail the build when can i deploy method is invoked and if verification was failed at provider side as we don?t return any exit code from the method ( can-deploy.js)?

@mboudreau @matt.fellows

I feel like I?m missing something important that would trivialize this, but I can?t figure out what :cold_sweat:

I haven't seen the API for can I deploy in JS yet so can't comment I'm afraid

Sure. So usually you have an http client that is configurable. When you setup your consumer application, you probably have to give it some information. Like where to find its provider (http url and path). Sometimes you can configure this with environment variables (e.g. `const providerBaseUrl = process.env.MY_PROVIDER_API = 'http://foo.com/path/to/api'`)

@dagarwal is this for pact-node?

because I'm fairly sure the pact-node version throws an error

Sounds about right to me. Can you programmatically detect which contract failed?

hm, that I do not know. My gut says no, it just does the exit code but no extra data

that sounds like a great feature to have though

not sure how feasible it is with the current ruby binary however

I know that HA proxy is in the mix there - who manages that? The provider or another team? So this is the setup in prod: `[consumer] -> [HAProxy] -> [provider]` right? HAProxy is responsible for adding the `/api` bit of the path and performing the routing to the provider. If this is _not_ tested as part of provider verification (ie. you verify by pointing directly at the provider, bypassing HAProxy, which I?m guessing is the case) then you only have 3 options: 1. Put in a path that omits the `/api` is part of your consumer tests, but make sure the configuration in production puts this there. 2. Test the provider _via_ the HAProxy service 3. Wrap the provider in a teeny lightweight proxy when you test it, so that the paths don?t get out of alignment

yes pact node .so when i use canDeploy we have console error as of now so even if i catch the error , build keeps on going and does not fail

That makes sense, thanks a lot for sharing, Matt! :bow: I?ll discuss the options with the team and go from there. Do you think a feature request for it for Pact would fly? Another optional entry to the contract in `providerPath: string`?

It?s worth tabling. I can see it helping some, like yourself :slightly_smiling_face:

and no probs@

if you catch the error without throwing another one, it'll gobble it up

what are you using for your build system?

jenkins

okay, and how do you run it? what's the command?

i am runnign like this return pactNode.canDeploy(checkVerification).then(() => { console.log(?Verified can i deploy against service?); }).catch(err => { console.log(?Verification failed for can i deploy against service?,err); });

i am doing like this in code and runnign the js file on jenkins

simply with node ?FileName?

right, like I said, since you're catching the error, it never bubbles up to the node top level and thinks you handled it appropriately

no even if i dont have catch in it, it does not fail my build

there's a few different ways of doing it, one is to just throw the error again: ``` return pactNode.canDeploy(checkVerification).then(() => { console.log(?Verified can i deploy against service?); }).catch(err => { console.log(?Verification failed for can i deploy against service?,err); throw err; }); ```

ah right, because it's a promise. You're probably not using something that handles promises in that way

yes

it just gives unhandled warning

and the build goes on

yeah

one way of doing it is to just do `process.exit(1);` when the catch happens

it'll make the program quit with an error code and jenkins will see that as a failed build

so whats the way then ? i tried wrapping up the logic in test and did add expect condition to fail it .But i was being suggested its not a test .its part of build .

okay i will try with process.exit and see

Also worth checking your Jenkins config. Make sure that any shell environment that you?re running in will also fail on non-zero exit codes

i.e. in in bash, make sure `set -e` is set

okay will check

:thumbsup:

it worked that way , thanks :slightly_smiling_face:

great!

Specifically, which way worked?

the process.exit way :wink:

yeah that way :stuck_out_tongue: but it would be good if canDeploy method return the same as its actually checking for if we can deploy or not so it should fail the build :slightly_smiling_face:

Process.exit is an antipattern for libraries - it makes sense for cli tools which check for error codes. Throwing errors or rejecting promises is much more idiomatic in JS. Errors are values and can be used as control flow. Process.exit is a blunt hammer

oh i see ..makes sense

:ok_hand:

Thanks Rashi - i?m actually doing a few things now, will look at this :slightly_smiling_face:

has joined #pact-js

i m getting the issue while i m running the Pact Workshop - js Error: Error from response: undefined at request.get.query.then.err (D:\Pact\pact-workshop-js-master\consumer\client.js:33:15) at process._tickCallback (internal/process/next_tick.js:68:7)

At which step? What have you tried to fix it?

has joined #pact-js

I m following the instructions given in the github page.I m first running the provider.js and in the seperate terminal i m running the Consumer.js file,while running consumer.js file i m getting the error that i have stated above.

has joined #pact-js

Hey @matt.fellows any update on this spike? I think this looked really good, do you have any plans to add it in a future release?

I plan on releasing in the next drop. Did you have any comment or feedback? Even a thumbs up on that issue would be great

I?ll write down some feedback soon.

that?d be awesome

I have an endpoint in my app which is like, `/api/actions?context=type;type=publish;assetIds=10006` with different matrix params `;` now when i create a consumer test with the same path, it throws `500` error. Can anyone here let me know how this can be fixed ? TIA

you may need to URLencode your path, I had the same issue sending `somepath/£$%` which becomes `somepath%2F%C2%A3%24%25` when encoded. In JS `const path = encodeURI("£$%");`

has joined #pact-js

this didn't solve my issue :disappointed:

Can you please share your test code so we can see? Logs would he nice too

Hi Matt, this is my test code, ``` describe('Getting available action for publish', () => { before(() => { return provider.addInteraction({ given: 'GET call', uponReceiving: 'Get available action', withRequest: { method: 'GET', path: "/api/actions?context=type;type=publish;assetIds=10006" }, willRespondWith: { status: 200, headers: { 'Content-Type': 'application/json' }, body: actions } }); }); it('Get available actions for publish', () => { return request.get(`http://localhost:${PORT}/api/actions?context=type;type=publish;assetIds=10006`) .set({ 'Accept': 'application/json' }).then((response) => { return expect(Promise.resolve(response.status)).to.equal(200); }).catch(err => { console.log("Error in available actions", err); }); }); });``` and this is the logs which i get when i run the consumer tests,

and this is the logs,

Thanks. I can take a look later when back at a desk

thank you :slightly_smiling_face:

I'm actually not sure if or how we support matrix params.

What do the pact logs say?

From that, it just didn't match

i see status `500` response in pact logs, ``` at process._tickCallback (internal/process/next_tick.js:180:9) status: 500, text: '{"message":"No interaction found for GET /api/actions?context=type;type=publish;assetIds=10006","interaction_diffs":[]}\n', method: 'GET', path: '/api/actions?context=type;type=publish;assetIds=10006' },```

like you said it is not matching with the path with matrix params

That's the unit test logs, I'm talking about the one pact itself generates

not sure... how can i get pact logs ?

There's an option in your pact test to specify where it goes. There is probably a log file in a `logs` or `pact` dir now