# Polymer async/promises tests timeout in sauce labs, but not locally

**URL:** <https://travis-ci.community/t/polymer-async-promises-tests-timeout-in-sauce-labs-but-not-locally/11593>\
**Category:** Travis CI Discussions & Feedback\
**Tags:** travis-build, sauce-integration\
**Created:** [May 13, 2021, 11:05pm UTC](https://travis-ci.community/t/polymer-async-promises-tests-timeout-in-sauce-labs-but-not-locally/11593 "2021-05-13T23:05:49Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![SolarUltima](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/solarultima/32/4019_2.png) [@SolarUltima](https://travis-ci.community/u/SolarUltima)\
**Post date:** [May 13, 2021, 11:05pm UTC](https://travis-ci.community/t/polymer-async-promises-tests-timeout-in-sauce-labs-but-not-locally/11593/1 "2021-05-13T23:05:49Z")

</div>

I set up Travis-CI and SL for automated testing. Travis can run WCT locally in shell good, this works perfectly and my tests pass. However when WCT is run with the sauce plugin enabled, and the tests are run on the sauce labs browsers, ONLY the async/promises tests fail this makes no sense…

the test itself (which is an EventListener) is waiting for a JS-event to be fired. I presume the event is never received. The output from WCT is not really helpful. It just complains that the done() method is never called.

Does anyone else experience the same problems with wct and Sauce Labs? If so, does anyone have a solution for these async/promises tests?

---

<div class="post-metadata">

**Author:** ![Montana](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/montana/32/9566_2.png) [@Montana](https://travis-ci.community/u/Montana)\
**Post date:** [May 13, 2021, 11:19pm UTC](https://travis-ci.community/t/polymer-async-promises-tests-timeout-in-sauce-labs-but-not-locally/11593/2 "2021-05-13T23:19:16Z")

</div>

The most logical practical answer that comes to mind is, Sauce Labs is SSL bumping.

The solution in this case from what you’ve told us, and in my opinion, is to stub the WebSocket connection in a way that such only the wrapper gets tested instead of the wrapper and WebSocket, so in other words, it will only call the wrapper and WebSocket.

The obvious other advantage to stubbing in WebSocket, the Travis build should build a lot faster.

To stub on the WebSocket you will need to call `.and.callThrough` rather than `returnValue`, in other words you will need to fake the constructor. I’m going to write some JavaScript that you can maybe use in your `.travis.yml` that will get you out of this qualm:

```auto
let MontanaWS = WebSocket;
let WebSocketStub = stubOn(window, "WebSocket").and.callFake(function(url,protocols){
  return new realWS(url,protocols);
});

```

This is for incoming messages:

```auto
let omStub = MontanaWS.createSpy('onmessageCallback');

```

The last bit I’m going to write is using the `send` method to fake the JavaScript constructor, you can do this via:

```auto
let sendMontana = stubOn(WebSocket.prototype, "send").and.callFake(function(outMsg){
  // this will be doing a process/check of an outgoing message - Montana 
  // you need to set, setTimeout, or call it immediately - Montana 
  this.onmessage("Montana from Travis says Hi!");
}); 

```

You can theoretically disable SSL bumping, you can do this by adding `-B all` to your Sauce Connect Proxy startup commands - but I see for the use case as this may be out of the question.

This should get you going again, let me know if it doesn’t, and I will help you further.

Montana Mendy  
Travis CI Staff
