Using jasmine custom matchers throw error during test with protractor v3.1.1

[giri-sh]

I am using jasmine custom matchers to test few things apart from standard set of function available. All was working fine when i had protractor v3.0. After updating to v3.1.1 i get jasmine spec timed out error with a lengthy expectation error message(which i feel is a promise object), whenever i use an custom expectation. Below is the error(truncated) i get -

A Jasmine spec timed out. Resetting the WebDriver Control Flow.

Expected ({ ptor_: ({ controlFlow: Function, schedule: Function, setFileDetector: Function, ... }) }) 
not to overlap 
({ ptor_: ({ controlFlow: Function, schedule: Function, setFileDetector: Function, getSession: ... }) }).

When i run the same code in older versions of protractor, everything works as expected. Thanks

[NickTomlin]

Interesting. I'm assuming this is due to the selenium upgrades in 3.1.0. Would it be possible to get an example spec/config that reproduces this failure?

Thanks!

[shahata]

I'm experiencing the same issue. This is actually due to an unintentional breaking change in angular/jasminewd@750898c by @juliemr

The problem is that matchers that return a promise in result.pass no longer work unless you pass a promise in expectation.actual.

For example:

jasmine.addMatchers({
  toHaveClass: function () {
    return {compare: function (actual, expected) {
      var ret = {pass: actual.getAttribute('class').then(function (classes) {
        var pass = !!(classes || '').match('(^|\\s)' + expected + '(\\s|$)');
        var positiveMessage = '\'' + classes + '\' did not contain class \'' + expected + '\'';
        var invertedMessage = '\'' + classes + '\' contained class \'' + expected + '\'';
        ret.message = pass ? invertedMessage : positiveMessage;
        return pass;
      })};
      return ret;
    }};
  }
});

This matcher no longer works since we use it like:

expect($('h1')).not.toHaveClass('kuku');

Because $('h1') is not a promise, the original wrapCompare is used and jasmine thinks that the result.pass promise that was returned by the custom matcher is just a truthy value

[juliemr]

Thanks for investigating, @shahata

We'll have to think about how we can support both custom matchers and the original done function inside timeouts (see comment #2894 (comment)).

[sjurba]

Hi, I'm having the exact same issue.

@juliemr it looks to me like you can fix this issue by calling the new compare function also when the actual and expected are not promises, but to check if the result.pass is a promise instead of using when(result.pass). I can whip up a quick pull-req if you want.