1

I know there is similar questions on here about this, but I cannot make sense of them for the life of me.

Here's an example, where I need to click a button and check the url.

My initial thought is I would write it as

element(by.id('button')).click();
expect(browser.getCurrentUrl()).toContain('asyncisconfusing');

I know the expect handles its promise but what about the .click? Shouldn't I have to write it like this?

element(by.id('button')).click().then(() => {
    expect(browser.getCurrentUrl()).toContain('asyncisconfusing')
})

Or is protractor/webdriver auto-magically doing this?

Community
  • 1
  • 1
Dinny
  • 59
  • 6

2 Answers2

5

In theory, since Protractor maintains a queue of promises via Control Flow and works in sync with an AngularJS application under test, you should not resolve promises explicitly unless you need a real value for further processing. In other words, this should be the prefferred form:

element(by.id('button')).click();
expect(browser.getCurrentUrl()).toContain('asyncisconfusing');

In practice though, explicitly resolving click() promises, or adding explicit waits via browser.wait() helps to deal with occasional and random timing issues.

alecxe
  • 462,703
  • 120
  • 1,088
  • 1,195
  • Gotcha, because the Control Flow is a queue. These timing issues would be caused by doing things outside the control flow when we shouldn't? or is the control flow order just something we shouldn't rely on? – Dinny Jul 21 '16 at 13:40
  • @Dinny we still should, but in real world, there are cases that still need special treatment. For example, the client-side animations, or the browser not being maximized, slow or unstable network related issues etc might cause the testing flow not be as natural as we might expect. For example, we have an Angular app under test, but in different parts of the codebase we had to add `browser.wait()` for, for example, wait for an element to become clickable or visible or the current url to contain an expected substring. In some places we have that `click().then()` part as well. – alecxe Jul 21 '16 at 13:48
  • That makes sense. We should be explicitly resolving promises and using `browser.wait()` when we can? or is this more case by case when you run into issues? – Dinny Jul 21 '16 at 14:38
  • @Dinny yeah, apply these things only in case you have issues, start with relying on control flow completely. – alecxe Jul 21 '16 at 14:39
  • thanks for the help and the quick responses. Happy Testing :) – Dinny Jul 21 '16 at 14:44
0

http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/lib/promise.html

The first section talks about how the control flow is used to manage promises without having to chain together every single command.

martin770
  • 1,271
  • 11
  • 15