mockServer does not `start()` about pact-js HOT 14 CLOSED

you're right @mefellows might update that now

from pact-js.

This seem to be related with pact-foundation/pact-js-core#20

from pact-js.

Will have a look at this today. Did you try installing a previous version of the library? The latest one went through a refactor last week and I wonder if it caused a side effect somewhere - or maybe it is really the pact-node issue you refer to.

Would you be able to tell 1) what environment are you on and 2) if you can try 1.0.0-rc.4 instead of the latest and how you go with it?

Thanks

from pact-js.

The environment this is running is:

npm:  3.10.3
node: 6.4.0

And I just tried the rc.4 release, but that did not work.

If I move the initialization of the variable provider outside the callback from the server start(). The pact interaction gets registered on the pact file. The test fails at the end, and during the execution I see this too:

 [SECURITY] node-uuid: crypto not usable, falling back to insecure Math.random()
 Unhandled promise rejection ProgressEvent { isTrusted: [Getter] } ( 6x)

from pact-js.

Moving the variable outside you can't be sure if the server really started.

I just noticed this line: Cannot read property 'finalize' of undefined

And also paying to attention to Jest, the async behaviour is different from Jasmine based on what I seen on the documentation and it doesn't look like it contains beforeAll and afterAll hooks like the latest versions of Jasmine do based on this part of the docs.

Maybe you have to adapt your code?

from pact-js.

Yes, that is what I am assuming. The undefined is because of that. provider is undefined until the server starts. It never starts it timeout and then run those lines for the afterEach and afterAll. Sure I will try that! thanks and I will update

from pact-js.

No worries @dolfo-pivotal - BTW first time I've seen someone using Jest with Pact. Would be great to have your contribution on a test case / doco 👍

from pact-js.

How did you go @dolfo-pivotal ?

from pact-js.

@tarciosaraiva this is my personal account. XD I could not allocated more work on the client, but I created a example using jest. https://github.com/rodolfo2488/pact-test-example/blob/master/client/__tests__/mainTest.js that works, but:

I have to tell jest to use the "node" testEnvironment

I get weird errors/warnings on the jsdom mode with jest like

crypto not usable, falling back to insecure Math.random()

ProgressEvent is untrusted

Note: this is because something is rejecting the request when it is by a script.

I could not use the pact.verify call

I need to read more the implementation of that method to see where I can fit that in the test. So far I am not using it.

I had to use cors true or it won't work

I have no clue why is this.

But I will continue working on that when I have time. A friend of mine started a project for spring boot verifier on the provider side that as well I am using it on the server side of that example. check that out.

Feel free to corrent my mainTest.js or suggest changes on it.

from pact-js.

hi @rodolfo2488 I think I identified the issue. Jest loads up JSDOM by default, even though the Jest configuration states that a browser environment is off by default.

This is causing Pact to instantiate a XMLHttpRequest object that is basically invalid:

    XMLHttpRequest {
      onabort: null,
      onerror: null,
      onload: null,
      onloadend: null,
      onloadstart: null,
      onprogress: null,
      ontimeout: null,
      upload: 
       XMLHttpRequestUpload {
         onabort: null,
         onerror: null,
         onload: null,
         onloadend: null,
         onloadstart: null,
         onprogress: null,
         ontimeout: null,
         _ownerDocument: Document { location: [Getter/Setter] } },
      onreadystatechange: null }

I'm digging further to see how we can fix this. Will keep you posted.

from pact-js.

OK @rodolfo2488 @dolfo-pivotal I understand what's going on now.

TL;DR: Jest uses JSDOM by default and brings along A LOT of polyfills to mimic a real browser environment (RBE) which passes the supporting libraries checks for RBE's thus using polyfills of questionable implementation.

JSDOM, as you know, is highly used by Facebook, Airbnb, etc to simulate a RBE in Node especially for React testing.

Most libraries that deal with HTTP/S requests that try to be universal usually check fora RBE like this:

    typeof window !== 'undefined' &&
    typeof document !== 'undefined' &&
    typeof document.createElement === 'function'

The code above is actually from axios and the full method is like this

function isStandardBrowserEnv() {
  return (
    typeof window !== 'undefined' &&
    typeof document !== 'undefined' &&
    typeof document.createElement === 'function'
  );
}

Pact JS does a similar check. I don't think JSDOM was meant to be used so heavily like this with real XHR objects being instantiated and requests making their way through - which actually work as you seen the log being populated - but the response somehow is not mapped correctly on the polyfill causing the request to fail and always be rejected by the Promise.

The guys from Jest thought about that and provided a configuration option named testEnvironment. If you set it to node then everything works.

I will be pushing an examples folder that contain a sample with Jest for Node. For the browser though, I strongly recommend you use something like Karma if you can.

Hope that helps and thanks for the issue. At least now I know that JSDOM might be something to look out for and potentially bring more support for React testing with Pact.

from pact-js.

hi @rodolfo2488 here's the example code based on your sample: https://github.com/pact-foundation/pact-js/tree/master/examples/jest

from pact-js.

Nice work @tarciosaraiva, is it worth noting this in the README more explicitly for future reference?

from pact-js.

I've updated the README with a reference to the details of this issue, closing.

from pact-js.