1

This is second part of: Expect: does not get the actual value

I was able to reproduce it a little bit better, so what I have:

expect((rfpPage.buttons.sendRequest).getAttribute('disabled')).toBe('true');

(rfpPage.inputs.firstName).sendKeys('Name');
(rfpPage.inputs.lastName).sendKeys('Surname');
(rfpPage.inputs.email).sendKeys('name@email.com');
(rfpPage.inputs.phone).sendKeys('1234312');
(rfpPage.inputs.company).sendKeys('Company');
(rfpPage.inputs.address).sendKeys('Leningrad Motorway');
(rfpPage.inputs.city).sendKeys('Moscow');
(rfpPage.inputs.postalCode).sendKeys('125171');
(rfpPage.inputs.eventName).sendKeys('Test Meeting');

expect((rfpPage.buttons.sendRequest).getAttribute('disabled')).toBe(null);

HTML: When form is not filled in:

<button type="submit" class="btn btn-lg btn-warning pull-right ng-binding" ng-disabled="!rfpForm.$valid || isWaitForRfp" disabled="disabled">Send Request
</button>

When the form is filled in:

<button type="submit" class="btn btn-lg btn-warning pull-right ng-binding" ng-disabled="!rfpForm.$valid || isWaitForRfp"> Send Request
</button>

What should happen:

  • All required fields are getting populated.
  • Send Request button becomes enabled (disabled attribute getting removed from DOM)

2nd expect fails saying expect true to be null.

This test worked JUST fine locally on 3-4 machines, on browserstack on multiple browsers, on saucelabs for several months.

*NOW: it started failing when it is getting executed via Jenkins on BrowserStack. If I run this test locally on remote desktop machine(from where Jenkins executes tests) it is still runs just ok. Locally on several machines it still runs ok. Locally on BrowserStack it runs ok. *

I have protractor 2.2.0 here and Jasmine 2.3.4

In my opinion something goes wrong with control flow, but really it is very strange stuff and I do want to explicitly wait for this attribute to be removed, because it will help, but looks like it is not proper solution.

2nd sample:

    expect(contactInfoPage.selectors.contactInfoSection.companyName.isDisplayed()).toBe(false);
contactInfoPage.selectors.contactInfoSection.isCorporate.click();
expect(contactInfoPage.selectors.contactInfoSection.companyName.isDisplayed()).toBe(true);

DOM before click:

<input tabindex="11" type="text" ng-model="contactInfo.companyName" id="companyName" ng-required="isCorporateEvent" class="ng-valid-maxlength ng-touched ng-valid ng-valid-required" maxlength="80">

DOM after click:

<input tabindex="11" type="text" ng-model="contactInfo.companyName" id="companyName" ng-required="isCorporateEvent" class="ng-valid-maxlength ng-touched required ng-invalid ng-invalid-required" maxlength="80" required="required">

Error: expect true to be false

Community
  • 1
  • 1
Sergey Teplyakov
  • 603
  • 8
  • 18

3 Answers3

1

I would actually use what webdriver has to offer - the isEnabled() check.

According to the webdriver spec, in it's logic it checks if a form element has disabled attribute:

Set enabled to false if a form control is disabled.

A form control is disabled if any of the following conditions are met:

  • The element is a button, input, select, or textarea element, and the disabled attribute is specified on this element (regardless of its value).
  • The element is a descendant of a fieldset element whose disabled attribute is specified, and is not a descendant of that fieldset element's first legend element child, if any.
expect(rfpPage.buttons.sendRequest.isEnabled()).toBe(true);
alecxe
  • 462,703
  • 120
  • 1,088
  • 1,195
  • yes, for this case it might be better to use isEnabled as out of the box solution, but looks like it is not the root cause of the problem in this case. I have added 2nd example to the question also, which also started suddenly failing with no reason – Sergey Teplyakov Sep 03 '15 at 14:08
  • @SergeyTeplyakov yeah, but why are you using `isDisplayed()`..instead of `isEnabled()`?.. – alecxe Sep 03 '15 at 14:09
  • Because for the 2nd my sample isEnabled returns true even before I click on the isCorporate checkbox. What really happens - element is not shown on the page, I click on the checkbox and addition form appears. In this case initially isDisplayed return false and after I click return true as expected. But for some reason this tests also started magically fail after several months that it was working properly. It is still working on all dev machines, but on Jenkins with BrowserStack it keeps failing – Sergey Teplyakov Sep 03 '15 at 14:17
  • @SergeyTeplyakov got it. Correct me if I'm wrong - you don't want to introduce explicit waits with `browser.wait()` to wait for element to become visible/invisible?.. – alecxe Sep 03 '15 at 14:18
  • Yes, I would like to avoid it, because looks like I am missing some basic thing here and I would like to understand what is wrong. Especially when these tests are working everywhere expect one remote PC with exactly the same configs and even on this PC everything work great locally... – Sergey Teplyakov Sep 03 '15 at 14:21
  • @SergeyTeplyakov I understand. I actually was in a similar situation and had to tweak my tests in order to make them reliably work on browserstack - had to add browser.waits.. – alecxe Sep 03 '15 at 14:23
1

Perhaps you just want to wait until the submit button is back to be clickable. Have you tried this?

  var EC = protractor.ExpectedConditions;
  browser.wait(EC.elementToBeClickable($('button[type="submit"]')), 10000);
nilesh
  • 14,131
  • 7
  • 65
  • 79
  • Yes, it could be consider as a workaround(I did it the same way for the other tests in quest N1), but I am trying to understand the real technical problem. Looks like protractor should handle such cases out of the box and this partical tests works fine on all dev machines / OS, but some magic of my lack of knowledge. It worked before for several months and started failing without any changes applied – Sergey Teplyakov Sep 03 '15 at 14:23
  • I don't think this is a workaround. Please note that the wait will NOT ALWAYS wait for 10s. It is the MAX time it will poll for element to be clickable. When you said it used to work and now fails only on certain machines, I realized this is a sync issue. Protractor wouldn't know application specific behaviors like yours for example. Its our job to make tests work the way we want with available API's. – nilesh Sep 03 '15 at 14:29
0

.IsEnabled() should work. Also I recommend to use elementexplorer to quickly figure out the result

Emile Muny
  • 1